Forums

Decorator idea

General discussion about Cobra. Releases and general news will also be posted here.
Feel free to ask questions or just say "Hello".

Decorator idea

Postby Charles » Sat Nov 03, 2012 2:32 pm

If you're not already familiar with it, check out the decorator pattern.

Now then, implementing it requires overriding every non-private member of the base component class which could get annoying if there are many of them and/or if they change frequently due to heavy development. This annoyance could be alleviated by code injection done by the compiler in response to a new Decorator attribute:

class Component

def foo
pass

def bar(i as int)
pass

def baz(s as String, i as int) as String
return s[i].toString

class ComponentDecorator inherits Component has Decorator

var _component as Component has Decorator

cue init(component as Component)
base.init
_component = component


Due to seeing the Decorator attribute on the class and on the var, the compiler would generate these:
class ComponentDecorator inherits Component has Decorator

# auto-generated:

def foo
_component.foo

def bar(i as int)
_component.bar(i)

def baz(s as String, i as int) as String
return _component.baz(s, i)

If you provided an implementation of any of the methods yourself, it would be skipped.

This would work the same whether the base component was an interface or a class.

Thoughts?
Charles
 
Posts: 2515
Location: Los Angeles, CA

Re: Decorator idea

Postby nerdzero » Sat Nov 03, 2012 8:54 pm

I think this is a great idea. Eliminates a lot of boilerplate.

If it's going to be baked in, what do you think about new keywords for this (e.g. decorates/decorated)? Such as...

class ComponentDecorator decorates Component

var _component as decorated

cue init(component as Component)
base.init
_component = component


Or is that just more syntax to remember?
nerdzero
 
Posts: 286
Location: Chicago, IL

Re: Decorator idea

Postby Charles » Tue Nov 06, 2012 12:52 am

It's a good question. Typically when Cobra supports a feature, there is custom syntax for it. We already have is-names like "public", "shared" and "override". So now I'm thinking:
class ComponentDecorator inherits Component is decorator

var _component as Component

...

This preserves the usual "inherits" syntax. You'll note that I didn't include anything new past that because it occurred to me that Cobra could take the first field typed the same as the base class (and generate an error if none exists), although that does repeat the type.

I debate whether the absence of any .init's should cause the compiler to provide the obvious one that takes the component.

Thoughts?
Charles
 
Posts: 2515
Location: Los Angeles, CA

Re: Decorator idea

Postby nerdzero » Tue Nov 06, 2012 1:00 pm

I'm gonna mull this over for a while. I have some knee jerk reactions but I don't trust them.

Anybody else have any opinions on this?
nerdzero
 
Posts: 286
Location: Chicago, IL

Re: Decorator idea

Postby hopscc » Wed Nov 07, 2012 5:40 am

I like the idea of having some support for decorators built into the language that elides the simple boiler-plate code delegation cases.

I'd prefer a specific keyword introduction syntax for it rather than an addition to is-names.
We've already chosen that path with mixin syntax ( adds )
- having this doesnt preclude an inheritance clause as well ( ... inherits ... decorates .... )
- currently I see is-names as specifying details like access control and override constraints (details of form) rather than
classes structure - pushing this into is-names would blur that severely..

for initializer methods my preference as already indicated was for a default no-arg init method to be synthesized if one is not specified ( boiler plate again) as was the original case - I dont see this as being any different.

Its all about minimising/removing unnecessary code noise and making code easy to comprehend ...
hopscc
 
Posts: 632
Location: New Plymouth, Taranaki, New Zealand

Re: Decorator idea

Postby hopscc » Wed Nov 07, 2012 6:21 pm

Also that if decorates is unclear as a keyword for this ,
(better) possible alternatives are
wraps or
encloses
( or augments even)

class ComponentAugmented inherits Base wraps Component
...

class ComponentAugmented inherits Piece encloses Component
...
hopscc
 
Posts: 632
Location: New Plymouth, Taranaki, New Zealand

Re: Decorator idea

Postby nerdzero » Wed Nov 07, 2012 6:29 pm

Charles, would this actually be implemented using an attribute regardless of Cobra syntax, or, in your initial post, was it a pseudo-attribute that the compiler would handle specially? Like could it be used just like any other attribute from a C# program the way the Visitor class in Cobra.Core can?
nerdzero
 
Posts: 286
Location: Chicago, IL

Re: Decorator idea

Postby nerdzero » Wed Nov 07, 2012 7:07 pm

hopscc wrote:Also that if decorates is unclear as a keyword for this ,
(better) possible alternatives are
wraps or
encloses
( or augments even)


I agree that these are better and more descriptive of what a "decorator" actually does, but I think since design patterns are about using common language/terminology to describe classes and their behavior it might add confusion to name it something else.
nerdzero
 
Posts: 286
Location: Chicago, IL

Re: Decorator idea

Postby hopscc » Thu Nov 08, 2012 5:51 am

Like mixins being introduced with adds ?

I'd disagree about the design-pattern-name vs description-of-what-it-does...

The descriptive name is better since it doesnt assume or demand a detailed knowledge of the exact design pattern being supported.
hopscc
 
Posts: 632
Location: New Plymouth, Taranaki, New Zealand

Re: Decorator idea

Postby nerdzero » Thu Nov 08, 2012 9:05 am

Yes, maybe. I guess it depends on if there is a precedent for it. Like using 'shared' instead of 'static' because VB does.

On the other hand, I admit I don't use the 'extend' keyword because I don't know what it actually does in terms of the code it will generate. Actually, now that I think about it, it seems like it would create a decorator. Is that true?
nerdzero
 
Posts: 286
Location: Chicago, IL

Next

Return to Discussion

Who is online

Users browsing this forum: No registered users and 124 guests

cron