[Laszlo-dev] Need uniform naming scheme for classes

P T Withington ptw at pobox.com
Wed Mar 12 04:45:50 PDT 2008


I want to have uniform names for user and LFC classes.  For now I am  
just using Lz + capitalize(tagname), but I would like to be able to  
use namespace:tagname some day...

On 2008-03-11, at 09:39 EDT, Henry Minsky wrote:

> We'll  still put a pointer to the class as an entry in the global  
> "lz",  I.e.,
>
> <class name="foo">
>
> gets a pointer as lz.foo, which is the documented way to access them.
> So the actual classname of a userclass  is going not going to be
> advertised to the users.
> It seems like $lzc$foo would be fine for a user-defined classname. We
> wouldn't be renaming
> and of the existing LFC classes, right?
>
> On Tue, Mar 11, 2008 at 8:13 AM, P T Withington <ptw at pobox.com> wrote:
>> I need to be able to name both user classes and built-in (LFC)  
>> classes
>> from their corresponding tag name.  In JS1 we can get away with
>> (effectively) saying:
>>
>> <class name="usertag" extends="anothertag"> ...
>>
>> maps into:
>>
>> class <unique prefix> + usertag extends ClassMap[anothertag] { ...
>>
>> but that is clearly not legal JS2.  [We need the unique prefix to  
>> keep
>> the class from shadowing any runtime class, e.g., the user class
>> `window` would shadow DHTML `window` otherwise.  In JS2 we can use a
>> namespace for this purpose.  We could extend the JS1 translator to
>> fake namespaces, but I don't want to take on that task at this  
>> point.]
>>
>> In the LFC there is a mapping from tag name to class name `view`
>> becomes `LzView`.  I'm not completely opposed to continuing that
>> practice, but I would prefer using our new convention of `view`
>> becomes `$lzc$view` because:  a) the leading `$` indicates that this
>> is not a public name, b) the interior `$` serves to delimit the  
>> prefix
>> from the tagname making it easier to unparse, and c) it is closer  
>> to a
>> namespace syntax.
>>
>> Comments?  Is this a useful change to make, or am I just making work
>> where it is not necessary?
>>
>
>
>
> -- 
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com



More information about the Laszlo-dev mailing list