Re: Finally ready to talk more substantively about 1.9 (and tng).

[Andreas Rottmann]

[CC'ing g-wrap-dev, since I want that archived]

Rob Browning <address@hidden> writes:

> Basically I'm concerned about exporting any overly generic names from
> our modules.  To some extent, generic functions do substantially
> alleviate the potential problems related to shadowing, collisions,
> etc., but I'm still concerned.  IMO it's tempting, and perhaps
> justified, to look at generic functions as a license to use any names
> without concern for collision or confusion because method dispatch
> will handle the ambiguities.  
>
Yeah, I kinda took that approach.

> However, it's my feeling that the main advantage to generics (in
> this area) is actually the fact that they allow you to define a
> given operation over all current and future classes, and to
> customize its operation in various contexts, but I feel like it's
> important that the underlying semantic operation associated with a
> given name be unique.
>
I'd restrict that to: the expression (GF-NAME VAR-NAME ...) should
clearly communicate the semantic the GF has in that context.

> As an example, I'd even be a little uncomfortable defining "close"
> for files and "close" for accounts. As an example, I'd even be a
> little uncomfortable defining "close" for files and "close" for
> accounts.  Given the possibilities afforded by subclassing, it can
> be very hard to tell what a given piece of code like this might do:
>
>  (for-each (lambda (f) (close f)) items)

This should be (for-each (lambda (file) (close file)) items) 

or the same with "account"; I think if you write it this way, it's
clear enough. When you use "short" names, you should/must make your
code clear via naming variables appropriatly.

[snip]

> with these more specific names it's a lot easier for the newcomer to
> the code-base to understand what's going on.  It's also easier for the
> authors if/when they even need to grep existing code to find all the
> occurrences of a given operation, or to change the name of a function.
>
I basically agree, but see above. Encoding the argument type in the
function name is what I want to avoid, since it is just useless typing
IMO, and unecessary with GOOPS. If you think of a mainstream OO
language, like Python, you wouldn't do this:

class File:
  def close_file():
    ...

but 

class File:
  def close():
    ....

I tend to think about generic function names *mostly* the same way as
about "mainstream" OO method names...

I agree that some names in G-Wrap are too generic (e.g. var), even
when considering them from my own POV ;).

> Another concern I have, though I'm not sure how important it is given
> guile module and goops specifics is what the possibilities are for
> shadowing and collisions.  For example, what if the user does this:
>
>   (define (type my-objects-derived-from-g-wrap-objects)
>     ...)
>
> in their code, not knowing offhand that we export "type"?
>
It won't have any influence on the G-Wrap modules, but the user will
have a hard time ever getting access to our "type".

> I actually don't know the answer, but I was wondering about both
> that, and the related issues with local lets, non-functional
> variable definitions like (define var 'my-stuff), etc.  I'm not sure
> what the 1.6 and 1.7 module systems do, or how goops and generics
> interact.
>
You export generics in one place and then add specializations to them
in various modules (all importing the first module). This is the
"normal" case. When two modules define a generic "foo" and add methods
to it, you can still use both of them with the "#:generic merge"
module argument, so you'll get what you expect, unless the two modules
have methods with the same signature.

> In any case, my current feeling is that generic function names should
> err toward being more specific unless there's a good justification
> that the operation in question [...]
>
> In our case, I don't actually care about whether or not we use any
> consistent prefix like gw:, gw-, or whatever, but my basic sense is
> that we should be exporting names more specific than type, var, value,
> arguments, options, etc.
>
I agree that these names are a bit overly generic. I'll quote the list
of maybe too generic (g-wrap) exports here, so we can discuss about
name changes.

   description

I think that can be justified since the semantic operation would be
"returns the description, which is a string".
   
   typespec 

typespec is OK, I think - its already a g-wrap specific term.

   c-name
   argument-count input-argument-count optional-argument-count
   arguments argument-types
   return-type return-typespec
   generic-name 

Hmm, have no suggestion for those -- mostly OK, except c-name,
perhaps.

   class-name type options c-type-name all-types add-option!

class-name is problematic, since it is the best name I could come up
with and taken by GOOPS (with a non-generic). I currently upgrade the
GOOPS function to a generic and export that, which leads to an
(unjustified) deprecation warning... If you can come up with a better
name, please do.

   var wrapped-var
   
Hmm, variable-name and wrapped-variable-name? A bit long, but bearble
I think.

   visible? default-value number name render no-op?
   
I think render and number are overly generic. I like "name", tough, as
you can just say (name type).
   
> Hope that made sense, and how do you feel about it?
>
It does, the problem is finding not-too-long, sensible alternative
names.

> (Oh, and given what I've grokked so far, nice work BTW.)
>
Thanks!

Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

It's *GNU*/Linux dammit!