I'm looking for a couple of things. Suggestions only mind but here goes.
I've found the observer pattern very useful in JAVA, with one caveat, the
fact they made it an object that you have to inherit from. Bang goes your
single inheritence. But to define it as an interface would mean implementing
the behaviour each time. Yuck.
<Puts on fireproof suit :o) >
So whats the option. Is there some way in the language we can have something
like
class Observeable {
notifyObservers();
}
class B encaptulates Observeable {
}
where what would actually happen is that the compiler would generate
class B {
notifyObservers();
}
So the funtionality of Oberver is encapsulated in B. In this way Observer
would work. Overloading of the method is not allowed. Although maybe you
could sub-class Observable itself. Then again maybe not.
Now I know this looks alot like multiple inheritence, but if the compiler
barfed if the user added a function notifyObservers() to class B then it
would overcome the issue.
Multiple inheritence is difficult and prone to error, but single inheritence
is very restrictive.
Don

I've found the observer pattern very useful in JAVA, with one caveat,
the fact they made it an object that you have to inherit from. Bang
goes your single inheritence. But to define it as an interface would
mean implementing the behaviour each time. Yuck.

I think the solution to this type of problem is
mixins. A mixin is a piece of data and functionality
that can be aggregated into another class. I like
to explain these types of with concrete examples.
Lets take the observer pattern mentioned above. Lets
also say for the moment that D has a preprocessor like
C does. I'm not saying that D should have a preprocessor,
I'm just using it as a device to explain the idea I'm
getting to below.
The observer interfaces...
interface IObserver
{
void update(IObserver from, Object obj);
}
interface IObservable
{
void addObserver(IObserver obs);
void deleteObserver(IObserver obs);
void deleteObservers();
int countObservers();
boolean hasChanged();
void notifyObservers();
void notifyObservers(Object obj);
}
So you want class Foo to be observable. That means
that you must specify IObservable as an interface
Foo implements. But then you have to actually implement
all the functionality that is in IObservable. As noted
this is rather tedious to do for every class that you
want to be Observable. But suppose you made a proprocessor
macro.
#define IMPLEMENTS_OBSERVABLE \
IObserver[] observers; \
bit changed; \
void addObserver(IObserver obs) \
{ \
observers ~= obj; \
} \
void notifyObservers() \
{ \
for(int i = 0; i < observers.length; ++i) \
observers[i].update(this,null); \
}
I'm not going to create the whole macro but you get the idea.
So now you can make Foo line this...
class Foo : BaseClass, IObservable
{
IMPLEMENTS_OBSERVABLE
}
This works but it uses a macro preprocessor that D has doesn't
have for various good reasons. So I might suggest something
like this.
struct Observable
{
IObserver[] observers;
bit changed=false;
void addObserver(IObserver obs)
{
observers ~= obj;
}
void notifyObservers()
{
for(int i = 0; i < observers.length; ++i)
observers[i].update(this,null);
}
// Other functions
}
class Foo : BaseClass, IObservable
{
mixin Observable a;
}
This is better than the macro. The Observable struct can
be syntax checked at the point it's defined. All the
functions in Observable could automatically generated in Foo
be generating functions like...
void addObserver(IObserver obs) { a.addObserver(obs); }

Yes exactly but I was thinking along the lines of the compiler inserting the
binary code of the Observable class in the, implementing object (okay so
it's not really implementing because it's not an interface it's a compiled
mixin object) rather than using macros. So in effect there is a language
keyword that supports the observable macro. Now I agree we cannot add
keywords for too many things otherwise there is a keyword explosion. But
some the Gamma patterns are used frequently these days and it would be nice
for them to be language contsructs.
I was glad when I switched to JAVA and dumped macro's, hopefully, for good.
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns92128C2162F8Epatcodemooncom 63.105.9.61...

I've found the observer pattern very useful in JAVA, with one caveat,
the fact they made it an object that you have to inherit from. Bang
goes your single inheritence. But to define it as an interface would
mean implementing the behaviour each time. Yuck.

I think the solution to this type of problem is
mixins. A mixin is a piece of data and functionality
that can be aggregated into another class. I like
to explain these types of with concrete examples.
Lets take the observer pattern mentioned above. Lets
also say for the moment that D has a preprocessor like
C does. I'm not saying that D should have a preprocessor,
I'm just using it as a device to explain the idea I'm
getting to below.
The observer interfaces...
interface IObserver
{
void update(IObserver from, Object obj);
}
interface IObservable
{
void addObserver(IObserver obs);
void deleteObserver(IObserver obs);
void deleteObservers();
int countObservers();
boolean hasChanged();
void notifyObservers();
void notifyObservers(Object obj);
}
So you want class Foo to be observable. That means
that you must specify IObservable as an interface
Foo implements. But then you have to actually implement
all the functionality that is in IObservable. As noted
this is rather tedious to do for every class that you
want to be Observable. But suppose you made a proprocessor
macro.
#define IMPLEMENTS_OBSERVABLE \
IObserver[] observers; \
bit changed; \
void addObserver(IObserver obs) \
{ \
observers ~= obj; \
} \
void notifyObservers() \
{ \
for(int i = 0; i < observers.length; ++i) \
observers[i].update(this,null); \
}
I'm not going to create the whole macro but you get the idea.
So now you can make Foo line this...
class Foo : BaseClass, IObservable
{
IMPLEMENTS_OBSERVABLE
}
This works but it uses a macro preprocessor that D has doesn't
have for various good reasons. So I might suggest something
like this.
struct Observable
{
IObserver[] observers;
bit changed=false;
void addObserver(IObserver obs)
{
observers ~= obj;
}
void notifyObservers()
{
for(int i = 0; i < observers.length; ++i)
observers[i].update(this,null);
}
// Other functions
}
class Foo : BaseClass, IObservable
{
mixin Observable a;
}
This is better than the macro. The Observable struct can
be syntax checked at the point it's defined. All the
functions in Observable could automatically generated in Foo
be generating functions like...
void addObserver(IObserver obs) { a.addObserver(obs); }

I managed to find the code inlusion in another language called Sather.
Sather defines a keyword called partial. To quote
"Partial classes define code that does not have corresponding objects or
type, and may be included by other classes to obtain implementation.
"Don Stewart" <donald.m.stewart btinternet.com> wrote in message
news:ac698h$280c$1 digitaldaemon.com...

Yes exactly but I was thinking along the lines of the compiler inserting

the

binary code of the Observable class in the, implementing object (okay so
it's not really implementing because it's not an interface it's a compiled
mixin object) rather than using macros. So in effect there is a language
keyword that supports the observable macro. Now I agree we cannot add
keywords for too many things otherwise there is a keyword explosion. But
some the Gamma patterns are used frequently these days and it would be

nice

for them to be language contsructs.
I was glad when I switched to JAVA and dumped macro's, hopefully, for

I've found the observer pattern very useful in JAVA, with one caveat,
the fact they made it an object that you have to inherit from. Bang
goes your single inheritence. But to define it as an interface would
mean implementing the behaviour each time. Yuck.

I think the solution to this type of problem is
mixins. A mixin is a piece of data and functionality
that can be aggregated into another class. I like
to explain these types of with concrete examples.
Lets take the observer pattern mentioned above. Lets
also say for the moment that D has a preprocessor like
C does. I'm not saying that D should have a preprocessor,
I'm just using it as a device to explain the idea I'm
getting to below.
The observer interfaces...
interface IObserver
{
void update(IObserver from, Object obj);
}
interface IObservable
{
void addObserver(IObserver obs);
void deleteObserver(IObserver obs);
void deleteObservers();
int countObservers();
boolean hasChanged();
void notifyObservers();
void notifyObservers(Object obj);
}
So you want class Foo to be observable. That means
that you must specify IObservable as an interface
Foo implements. But then you have to actually implement
all the functionality that is in IObservable. As noted
this is rather tedious to do for every class that you
want to be Observable. But suppose you made a proprocessor
macro.
#define IMPLEMENTS_OBSERVABLE \
IObserver[] observers; \
bit changed; \
void addObserver(IObserver obs) \
{ \
observers ~= obj; \
} \
void notifyObservers() \
{ \
for(int i = 0; i < observers.length; ++i) \
observers[i].update(this,null); \
}
I'm not going to create the whole macro but you get the idea.
So now you can make Foo line this...
class Foo : BaseClass, IObservable
{
IMPLEMENTS_OBSERVABLE
}
This works but it uses a macro preprocessor that D has doesn't
have for various good reasons. So I might suggest something
like this.
struct Observable
{
IObserver[] observers;
bit changed=false;
void addObserver(IObserver obs)
{
observers ~= obj;
}
void notifyObservers()
{
for(int i = 0; i < observers.length; ++i)
observers[i].update(this,null);
}
// Other functions
}
class Foo : BaseClass, IObservable
{
mixin Observable a;
}
This is better than the macro. The Observable struct can
be syntax checked at the point it's defined. All the
functions in Observable could automatically generated in Foo
be generating functions like...
void addObserver(IObserver obs) { a.addObserver(obs); }

I managed to find the code inlusion in another language called Sather.
Sather defines a keyword called partial. To quote
"Partial classes define code that does not have corresponding objects or
type, and may be included by other classes to obtain implementation.

I find myself wanting this type of functionality all the time. But I'm not
sure that there isn't a better way.
Sean

I managed to find the code inlusion in another language called Sather.
Sather defines a keyword called partial. To quote
"Partial classes define code that does not have corresponding objects or
type, and may be included by other classes to obtain implementation.

I find myself wanting this type of functionality all the time. But I'm