Decorator idea

[Charles]

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?

[nerdzero]

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?

[Charles]

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?

[nerdzero]

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?

[hopscc]

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]

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
...

[nerdzero]

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]

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.

[hopscc]

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.

[nerdzero]

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?