> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to