Login | Register
My pages Projects Community openCollabNet

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author =?ISO-8859-1?Q?David_Z=FClke?= <dz@bitxtender.com>
Full name =?ISO-8859-1?Q?David_Z=FClke?= <dz@bitxtender.com>
Date 2007-11-16 07:22:12 PST
Message Another thing we could consider is an approach similar to phpAspect's
where source is transformed using XSLT via the parse tree... that
would, actually, be the nicest solution, if it can be done in a simple
fashion and without (any|too many) external dependencies.


Am 16.11.2007 um 15:44 schrieb Hans Lellelid:

> David Z├╝lke wrote:
>> How bout something wicked such as having method bodies in an array,
>> with
>> each line having a unique ID ;) That would be hax0r.
>> But seriously - yes, we need something like that. The more modular it
>> is, the better. But as you pointed out, it could be a bitch to
>> design -
>> maybe we need alien technology from outer space to do that. Not quite
>> sure... :>
>> David
>> Am 16.11.2007 um 14:58 schrieb Ron Rademaker:
>>> Hans Lellelid wrote:
>>>> It becomes a little less clear to me when I think about a builder
>>>> advertising that it wants to override / customize other methods. I
>>>> guess the question is what happens when several builders want to
>>>> all add
>>>> custom behavior into the save method?
>>> I guess we could reevaluate the way classes are generated
>>> completely.
>>> Instead of passing along some string by reference and appending code
>>> in a function we could model the classes that are being generated
>>> and
>>> let the builders fill the model. Finally, some toString function on
>>> the model class creates the actual code. That way you don't have to
>>> create an entire function in one sweep but you can add, remove and
>>> change stuff later. Obviously, the model is gonna be a challenge to
>>> design :)
> Yeah, that's a possibility. I looked into that a bit when considering
> the initial design. In the end, I opted for the current system,
> because
> I think it's a lot easier for people (including myself) to understand.
> I worry about completely abstracted code generation being really
> difficult to get in there and change :)
> Maybe the initial pass continues to use a template-based approach
> and we
> look at revamping this based on usage / needs.
> Hans
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org