[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Object epiphany: A new way of building widget applications
Mark Hadfield wrote:
> "JD Smith" <firstname.lastname@example.org> wrote in message
> > Martin Schultz wrote:
> > >
> > > With almost a week delay, I finally get around to release the first
> > > version of a new class of IDL objects: the MGS_GUIObject hierarchy.
> > I think it only fair to let people know that I tend to shy away from
> > distributed code with people's initials in the name. I know, it sounds
> > stupid, but I'm not sure I'm the only one. It seems to be a reasonably
> > common practice here (Craig, you listening?), but one which I think
> > might be best to avoid, for the following reasons:
> As one of the pioneers of this trend (he says modestly) may I present the
> opposing viewpoint:
> It's namespace management, pure and simple. It's desirable because IDL lacks
> built-in facilities.
> > And the way I think
> > about it, since IDL doesn't do any shadow checking (but cf. idlwave!),
> > the *best* routine with a given generic name will rise to the top.
> The one that rises to the top is somewhat unpredictable. (Well, strictly
> speaking it's predictable because yuu can control your PATH, though I have
> noticed recently that Windows 2000 expands path entries preceded by + in
> *reverse* alphabetical order, which caused me some grief.) The thing is, I
> don't remember exactly what is where on my PATH and I don't like relying on
> the search order. I have been bitten by duplicated routine names a number of
> times: CALDAT and CREATE_STRUCT are two I can remember.
I of course am very sensitive to this notion, which is why Carsten and I
developed an effective method for dealing with it in IDLWAVE. But in
any case, I was merely speaking metaphorically. If I write a routine
called "stack", and you write a routine called "stack", one or the other
will probably come into dominant usage. Is this ideal? No. Should we
attempt to relieve namespace collision by thinking ahead? Certainly.
> > 4. The author(s) can always be found in a proper documentation header.
> Sure, but it's not about claiming ownership, it's about namespace
> But hey, there's room for all points of view. If you don't prepend your
> initials and I do, then our routine names will never clash.
> Is there any other MGH out there?
If you need a prefix to differentiate your namespace, then by all means,
chooose one. I was just arguing against that prefix being your
initials. Here is an decent argument, simultaneously *for* namespace
management, and *against* using your initials:
It's for lisp, but the same arguments apply. It's also pretty
simplisitic, but the basic tone captures it I think. So, for your
example, suppose you have a stack class which is fairly general. Why
not super_stack, or fast_stack, or objStacker, etc? Yes, IDL started
this whole ball rolling with their IDL_Blah series of classes, but I
guess I just feel like a more open approach is available to us here.
If I were a company, JD, Inc., I would give my products a strong brand
identity: JDI_Widget.pro. I'm not a company, and for this I'm glad. I
don't make money from the things I contribute, nor do I guarantee their
utility. If they solve your problem, great. If you rip them into
pieces to something altogether different with them, great.
I'm not saying you *shouldn't* brand your contributions in the same way,
but just pointing out a (perhaps not universal) connotation that