[kamaelia-list] Re: Autoloading Components based on Imports

2009-06-23 Thread Matt Hammond

 So some questions arise:
1. Good idea or not?
2. Really? Could be viewed as bad mojo  messing about one step too
 far.
3. If OK, should it be static? ie the list of what gets imported and
handles what dealt with by a table lookup in Kamaelia/__init__.py ?
4. Or should it go OK, I was imported here, I'll rummage around in all
 my
subdirectories, in this overall order
5.  Do 3, then 4, if the name wasn't found in 3.
6. The other way round ?
7. Do we allow extra search paths for the case of 4 ?  (think sys.path
 for
modules)
8. How about allowing extra lookup tables to be added in the case of 3?
9. lots more possibilities.

I can see it would be much less verbose and that is a *good* thing! If
nothing else, from writing examples in documentation, where brevity is
highly desireable, adding all those import statements can be tedious and
ugly.

I would also worry about the situation where two or more components share
the same (leaf) name. Eg:

  Kamaelia.Chassis.Pipeline
  Kamaelia.Experimental.Chassis.Pipeline

There are also other components which, although they do not clash now,
look likely to later, eg:

  Kamaelia.Audio.Codec.PyMedia.Decoder.Decoder

I suppose I'm asking, will someone's code break X months/years later when
more components are added to teh repository with the same name? This
concern therefore makes me worry this could be a short term gain which
causes future difficulties.

But maybe this is still a good idea and the solution is to develop a
stricter component naming policy? (and retrospectively rename existing
components to fit it)

Another perspective: If one of the problems this is trying to solve is
disagreement over where a component should be located in the hierarchy;
this could be solved by symlinking - ie. let the component be in both
places in the hierarchy where it is believed to make sense.

However, I guess this could end up being highly confusing! I can see it
would make sense if you consider the hierarchy as a hierarchical
classification scheme, rather than a packaging/encapulsation thing - eg.
more like categories on Ebay than packages in java.



-- 
| Matt Hammond
|
| [anything you like unless it bounces] 'at' matthammond 'dot' org




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
kamaelia group.
To post to this group, send email to kamaelia@googlegroups.com
To unsubscribe from this group, send email to 
kamaelia+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/kamaelia?hl=en
-~--~~~~--~~--~--~---



[kamaelia-list] Re: Autoloading Components based on Imports

2009-06-23 Thread Sylvain Hellegouarch

Matt Hammond a écrit :
 So some questions arise:
1. Good idea or not?
2. Really? Could be viewed as bad mojo  messing about one step too
 far.
3. If OK, should it be static? ie the list of what gets imported and
handles what dealt with by a table lookup in Kamaelia/__init__.py ?
4. Or should it go OK, I was imported here, I'll rummage around in all
 my
subdirectories, in this overall order
5.  Do 3, then 4, if the name wasn't found in 3.
6. The other way round ?
7. Do we allow extra search paths for the case of 4 ?  (think sys.path
 for
modules)
8. How about allowing extra lookup tables to be added in the case of 3?
9. lots more possibilities.
 

 I can see it would be much less verbose and that is a *good* thing! If
 nothing else, from writing examples in documentation, where brevity is
 highly desireable, adding all those import statements can be tedious and
 ugly.
   
True and yet I welcome that verbosity. I did a bit of Ruby and the first 
thing that annoyed me was that there was lots of magic going on in 
module finding and since the language allows you to change things rather 
dramatically at so many levels I ended up being lost and frustrated quickly.

I appreciate the fact that the current verbosity means I know where 
things are coming from and never worry about name clashing.

- Sylvain

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
kamaelia group.
To post to this group, send email to kamaelia@googlegroups.com
To unsubscribe from this group, send email to 
kamaelia+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/kamaelia?hl=en
-~--~~~~--~~--~--~---