Hi Sebastian,

thanks for your input. I can only speak for myself, but my interest as 
developer is to work with the existing classes instead of subclassing 
them as new ones. This is much more flexible and allows me to extend the 
behaviour of my application without having to rewrite a single line of 
the gui code or having to change qooxdoo source code and get out of sync 
with SVN etc. I think this is a valid concern even if some purist might 
shudder. Not everyone has the time to do things like in the text book, 
and we shouldn't force javascript to behave like a class-based language. 
Run-time property addition is a great tool to solve real problems.

So if you have good ideas for optimizing the property system, that's 
excellent. But I would ask you to create a parallel (slower) system 
which allows to override custom behaviour in "the old way".

Thanks,

Christian

Sebastian Werner schrieb:
> OK, lets me explain the benefits of this new version, when it comes, and 
> let us find solutions for your needs. Sometimes it's not the best 
> solution to try to keep an existing system, especially when they have 
> some design issues. It might be better to reinvent the wheel in some 
> cases. And we definitely try to find a way to solve the requirement of 
> custom properties, but this does not mean these must be real properties, 
> like previously known from qooxdoo.
>
> OK, let's begin. The reason for this new system would be a dramatically 
> better performance. The old system was somewhat over-engineered and 
> expensive. We need a system which scales as well as self-written 
> setters/getters. But we want this as comfortable and easy as previously. 
> The idea behind the new system is to do the things as lazy as possible. 
> The system also used advanced caching features to omit the double 
> creation of stuff. It will generate setters, which are highly tuned and 
> so use the optimal code, to do exactly what was defined by the 
> developer. It's the best code for this property, comparable with 
> hand-written code for each function. Also it's much easier possible to 
> reconfigure properties with the inheritance e.g. changing types, default 
> values, ...
>
> The only negative point would be, that it's not possible to change or 
> add properties after the first instance of the object has been created. 
> I think this is OK for real properties, but we definitely need a way to 
> let the non-framework developers attach data comparable to the old way.
>
> Details for this new system will be showed off in a few months. These 
> are just the first signs of the new API. Nothing finalized yet.
>
> Maybe there are already ideas for a better system - from the users view 
> (user data). Would it be enough to add validation, like in the current 
> properties, to the user data stuff? Do you need the event support for 
> your custom fields? We are open for discussion. Please place in your 
> ideas. Hopefully the results will be a good choice for all developers.
>
> Cheers,
>
> Sebastian
>
>
>
>
> Christian Boulanger schrieb:
>   
>> Sebastian Werner schrieb:
>>     
>>> <snip>
>>> I just mention this, because this will not work in the future. The plans 
>>> for a new property system doesn't allow the dynamic addition of 
>>> properties to previously defined classes.
>>>
>>> Maybe it's better to enhance the other properties to make it possible to 
>>> use them in a comparable way.
>>>   
>>>       
>> That's bad news! What would be the possible benefit? If that is the 
>> plan, this completely throws my migration plans out of the window. I am 
>> dependent on the ability to migrate the QxDataManager extensions, and 
>> the only way they will work is through the excellent existing system. I 
>> don't think native qooxdoo will ever support what QxDataManager does, so 
>> no new feature that you want to implement by abandoning run-time 
>> property additions can outweigh this.
>>
>> I would strongly suggest asking the userbase whether your idea is really 
>> welcome - I would consider this, by the way, good practice for any such 
>> far-reaching change. I personally would really regret it. These are my 
>> two cents.
>>
>> Cheers,
>>
>> Christian
>>
>>
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys -- and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>     
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>   


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to