On Wed, Mar 18, 2015 at 1:57 AM, Andy Wingo <wi...@igalia.com> wrote: > Hi, > > [-asmundak, as he probably doesn't care :)] > > On Tue 17 Mar 2015 23:21, Doug Evans <d...@google.com> writes: > >> On Tue, Mar 17, 2015 at 1:57 AM, Andy Wingo <wi...@igalia.com> wrote: >>>> As to the class of an object passed to a sniffer, how about calling it >>>> FrameData? Note that it's not very important from the user's point of >>>> view as sniffer code does not ever reference it by name. >>> >>> It's true that from user code it barely matters to Python, but Scheme's >>> monomorphic flavor makes these things more apparent: >>> >>> (frame-data-read-register frame "r0") >>> >>> This doesn't read so well to me -- is it "read-register" on a >>> "frame-data", or is it "data-read-register" on a "frame" ? A weak point >>> but "ephemeral-frame-read-register" avoids the question. >> >> As food for discussion, >> I know some people use foo:bar in Scheme to separate >> the object "foo" from the operation on it "bar". >> -> frame-data:read-register > > This convention is not often used in Guile. When it is used, it often > denotes field access rather than some more involved procedure call -- > similar to the lowercase "foo_bar()" versus camel-cased "FooBar()" in > Google C++ guidelines. > >> I like having some separator, but I went with what >> I thought was the preferred spelling (all -'s). >> It's not too late to change gdb/guile to use foo:bar throughout (IMO), >> but the door is closing. > > FWIW, I prefer "-".
Even though a different character solves a problem? What problem does it introduce? The comparison with _ vs CamelCase is apples and oranges. They don't separate object/class name from method name. If I were to invoke static method read_register on class ephemeral_frame it would be ephemeral_frame::read_register(). The problem of the readability of frame-data-read-register that ephemeral-frame-read-register attempts to solve just doesn't arise. Same with frame-data:read-register.
