Namespace, Psets, Order, IDs, Joy (was: Intent)

[Kyle Lahnakoski]

iepos@tunes.org wrote:
 
> > This brings up a question of mine concerning namespaces.  There is quite
> > a lot of talk of namespaces.  I am of the belief that namespaces belong
> > to the personal compiler/IDE of the programmer, not the system.
> 
> I guess I'd agree with that. I like the idea of a system not keeping
> source code around, but instead just keeping an internal version
> (possibly using something like your ID's instead of English-text
> function names) that can be more easily manipulated; then, if a coder
> wants to see a program, the system would generate the text on-the-fly
> to match the coder's preferences, such as the names and order of
> functions and pretty-printing styles, and the column width of his
> terminal.
> 
> Of course, there might be some cases where the coder really does
> want control over the exact layout of the code; for instance, this
> may be the case if one is writing a program for some Obfuscated
> Coding contest. In this case, some mechanism should still be provided
> so that the textual source code can still be worked with.

I consider that a word processing application.


> > > Anyhow, parameter-order is not the only seemingly-arbitrary thing
> > > that one must decide when making libraries. Another thing one must
> > > decide is the structure of how things are passed; will one pass
> > > several parameters in unwrapped form, or will one instead make
> > > a list ("object", "structure", or whatever) containing them and just pass
> > > that? Again, the pset approach has the same type of problem here
> > > as Joy.
> >
> > The solution I have is to ALWAYS pack the parameters into a message.
> > Commonly, object slots/fields are accessed like psets (a.setName("Kyle")
> > OR a.Name="Kyle).  Messages are objects, therefore uniformity says that
> > messages are populated like psets.  This appears quite clean to me.
> 
> Yes. But it does not entirely solve the problem. There is still the
> question of how the subcomponents of the message will be structured.
> For instance, suppose you are designing some function to put a
> character on a text terminal. It needs to take an "x" and "y" coordinate,
> plus a character to tell what to put there. Under your design, all
> the parameters will be packed into one pset before being passed
> to the function, but the question remaining is: will the "x" and "y"
> be packed into a Point or something before being put into the
> structure or will they just be put in the structure loose. It is
> very much an arbitrary decision.

Never thought of it that way; packing parameters in a message is an
issue belonging to the sphere of general abstraction techniques. 
Logically, I would put the x,y in a point object, and the point into the
message for sending.  For speed, and clarity, I would prefer to have
them loose.  Because I want the former for logical reasons, and the
latter for personal reasons, the resolution to this issue lies with the
compiler.  It would be trivial for the compiler to determine if the
parameters can be "flattened" for simple function calling, allowing the
user to specify both methods.

If the compiler does not support both call methods, the following is not
too bad:

	MyFunction(point=Point_Class.NewInstance(x=4, y=5), character='k');




> 
> > > Again, a similar problem happens in your style of system. A person
> > > who writes a library might go back and change the names of some of
> > > the parameters, and woe be unto everyone else who was using the
> > > old names. But actually, I don't see the problem quite happening this
> > > way; if I was "everyone else", then I would have made a local copy of the
> > > library instead of relying on the writer not to change it; then I would
> > > know that the parameter orders (or names) are not going to change.
> >
> > Changing the interface for a function; adding removing, changing meaning
> > of parameters, is a situation that both Joy and psets can not handle
> > well.  This is a different type of problem than just renaming, or
> > changing parameter order.  This problem is about defining totally new
> > interface/functionality.  The only solution I envision is to have the
> > re-implementor create a mapping from the old function interface to the
> > new one.  The Tunes-like system can then go to all apps that use the old
> > interface and alter them for the new one.
> 
> Hmm... I don't really see the original problem. I guess maybe you're
> supposing that the apps used the function by reference, so-to-speak,
> so that it would be expected that app be automatically updated if
> the function changed. However, I would like the system much better
> if the apps used the function by value, so that if one changes
> the function, the app will just continue peacefully using the old
> function.
> 
> I guess my confusion stems from talking about "changing the function";
> to me it seems misleading to talk about a function changing. What
> is probably really changing is the user's IDE, so that the same name
> becomes mapped to a different function. Or, perhaps the stack has
> changed, if one has popped one function off and pushed a different
> one on. Anyhow, it makes sense to me that if a user modifies
> a function by renaming that the change will only effect future
> uses of the name and only by that one user, so that the system
> need not go hunting around to change all the old apps.

"Changing the function" is misleading, but you are getting the point. 
Your solution is one possible, the other being altering the old callers
to compensate for interface change.  I believe that those solutions can
be generalized along with other temporal database issues with a firm
versioning system; I am trying to dream one up now.

> > ----------------------------------------------------------------------
> > Kyle Lahnakoski                                  Arcavia Software Ltd.
> > (416) 892-7784                                 http://www.arcavia.com
> 
> - "iepos" (Brent Kerby)

-- 
----------------------------------------------------------------------
Kyle Lahnakoski                                  Arcavia Software Ltd.
(416) 892-7784                                 http://www.arcavia.com