[Laszlo-dev] static (class) attrtibutes [Was: For Review: Change 20080405-ptw-k Summary: Fix components that use JS classes]

[P T Withington]

I have a plan!

It's just not implemented (yet).  It would not take much to add.  This  
is the plan:

A new property for <attribute>, `allocation`, which can be one of  
'instance' (default), 'class' (i.e., static), or 'each-subclass' (what  
we have to do by hand right now with the `attributes` attribute of  
LzNode.  [This syntax and meaning stolen from Dylan.]

Most of the support for instance/class allocation is already in the  
tag compiler.  It's just a matter of finishing the interface.  each- 
subclass would only be a teeny bit harder to do.

If you feel this is important to do sooner rather than later, please  
file an improvement request with this conversation as context.

On 2008-04-06, at 13:13 EDT, André Bargull wrote:
> Btw, to be able declare something as "static" was also requested a  
> few times in the forum.
>
>> The only other one I see is  "uid", which may be possible to store
>> some other way.  Maybe we need a UID generator API for the LFC ?
> There'll be another one: "_colorcache". Because I've just send a  
> changeset to declare it as static; atm it's implicitly static as it  
> is only defined on the prototype object.
>
> On 4/6/2008 6:55 PM, Henry Minsky wrote:
>> Or maybe we should add "static" as an option to declaring an
>> <attribute> in LZX?
>>
>>
>> On Sun, Apr 6, 2008 at 12:54 PM, Henry Minsky  
>> <henry.minsky at gmail.com> wrote:
>>
>>> I don't think we have any way to declare a static var in a LZX  
>>> class.
>>>
>>> But maybe you don't need them? What does drawview have that needs to
>>> be a static var?
>>> The 'tagname' and 'attributes' declarations will be supplied by the
>>> compiler automatically.
>>> The only other one I see is  "uid", which may be possible to store
>>> some other way.  Maybe we
>>> need a UID generator API for the LFC ?
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Apr 6, 2008 at 12:41 PM, André Bargull <a.bargull at intensis.de 
>>> > wrote:
>>> > Hm, I've just started to re-write drawview as a normal lzx- 
>>> class, but I
>>> > needed to suspend that idea after a few lines:
>>> >  The current lfc-like drawview implementation uses the "static"  
>>> qualifier,
>>> > but that's currently not available in the lzx-world, right!?
>>> >
>>> >
>>> >
>>> >
>>> >  On 4/6/2008 6:23 PM, André Bargull wrote:
>>> >
>>> > > Concerning drawview:
>>> > > I guess that needs/should be rewritten nevertheless, because  
>>> of the heavy
>>> > use of "lz.drawview.addProperty(..)", not really a good JS2  
>>> class-style.
>>> > >
>>> > > Generally, what information do you need at compile time to add
>>> > automatically that prefix "$lzc$class_" to a class name?
>>> > > And how are lzx-interfaces processed by the compiler? Is that  
>>> interface
>>> > definition only needed for the tag-compiler, so it knows that  
>>> i.e. drawview
>>> > extends LzView and is has got a few attributes and methods. Or  
>>> is it a 'real
>>> > interface', like in Java?
>>> > >
>>> > >
>>> > > On 4/6/2008 5:49 PM, P T Withington wrote:
>>> > >
>>> > > > I'm open to ideas, but there are a number of these  
>>> conventions that you
>>> > 'just have to know' if you are writing a class to implement a  
>>> tag.  It's not
>>> > expected that the LZX programmer will be doing this -- they  
>>> should just use
>>> > the <class> tag, which will handle all these conventions for them.
>>> > > >
>>> > > > In these particular cases, what is really happening is that  
>>> someone has
>>> > effectively broken a piece of the LFC out as a component, so  
>>> that it is only
>>> > loaded when needed.  And in this case, they have written an LFC- 
>>> style class,
>>> > which does require that they understand the inner workings of  
>>> how an LFC
>>> > class is used to implement a tag.
>>> > > >
>>> > > > On 2008-04-06, at 11:21 EDT, André Bargull wrote:
>>> > > >
>>> > > > > Approved, as usual I have no idea regarding the compiler- 
>>> stuff, but
>>> > hey, drawview works again!
>>> > > > >
>>> > > > >
>>> > > > > > // Classes that implement an interface must obey the LZX
>>> > > > > > // tag->class mapping convention
>>> > > > > >
>>> > > > > Should I file an improvement request, so the compiler will  
>>> perform
>>> > this mapping automatically, because writing "$lzc$class_foobar"  
>>> isn't really
>>> > intuitive.
>>> > > > >
>>> > > > >
>>> > > > > On 4/5/2008 8:26 PM, P T Withington wrote:
>>> > > > >
>>> > > > > > Change 20080405-ptw-k by ptw at dueling-banjos.local on  
>>> 2008-04-05
>>> > 14:12:50 EDT
>>> > > > > >   in /Users/ptw/OpenLaszlo/ringding-clean
>>> > > > > >   for http://svn.openlaszlo.org/openlaszlo/trunk
>>> > > > > >
>>> > > > > > Summary: Fix components that use JS classes
>>> > > > > >
>>> > > > > > Bugs Fixed:
>>> > > > > > LPP-5700 'drawview broken'
>>> > > > > >
>>> > > > > > Technical Reviewer: a.bargull at intensis.de (pending)
>>> > > > > > QA Reviewer: promanik (pending)
>>> > > > > >
>>> > > > > > Details:
>>> > > > > >   NodeModel: Consider interfaces and mixins for  
>>> getParentClassModel
>>> > > > > >
>>> > > > > >   ClassModel: Store the 'kind' (class, interface,  
>>> mixin), don't
>>> > > > > >   generate any code for interfaces (for now).
>>> > > > > >
>>> > > > > >   drawview, richinputtext, lazyreplicator, replicator:  
>>> Obey the new
>>> > > > > >   LFC tag class conventions.
>>> > > > > >
>>> > > > > > Tests:
>>> > > > > >   drawview examples work again
>>> > > > > >
>>> > > > > > Files:
>>> > > > > > M      WEB-INF/lps/server/src/org/openlaszlo/compiler/ 
>>> NodeModel.java
>>> > > > > > M
>>> > WEB-INF/lps/server/src/org/openlaszlo/compiler/ClassModel.java
>>> > > > > > M      lps/components/extensions/drawview.lzx
>>> > > > > > M      lps/components/extensions/views/richinputtext.lzx
>>> > > > > > M      lps/components/utils/replicator/lazyreplicator.lzx
>>> > > > > > M      lps/components/utils/replicator/replicator.lzx
>>> > > > > >
>>> > > > > > Changeset:
>>> > http://svn.openlaszlo.org/openlaszlo/patches/20080405-ptw-k.tar
>>> > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Henry Minsky
>>> Software Architect
>>> hminsky at laszlosystems.com
>>>
>>>
>>
>>
>>
>>