Heritage

Heritage

[David Baelde]

Hi list,

We're getting crazy with some design problem. We need to design a
buffer object and be able to extend it with some features
(lexing,color highlighting... yes we're working on an editor). Here's
the problem.

I'd like to have a class (or function) for every extension. For
example be able to write
new parsed (new lexed (new basic)). I.e. I would need the class:

class lexed buf =
object inherit buf method get_token = ... end

It doesn't work cause inheritance is only from classes, not objects.
But I want buf to be of any class (any super-class of buffer actually)
but I don't want to coerce buf to type buffer, cause I want to keep
extra methods if any were added.

I'd like to know if there's any simple example of why
object-inheritance is forbidden, and if any of you have an idea for
that problem..

Thanks.
-- 
David

Re: [Caml-list] Heritage

[Corey O'Connor]

For something that provides the functionality of runtime inheritance
check out the Decorator pattern.
http://www.dofactory.com/Patterns/PatternDecorator.aspx

Essentially the deccorator pattern is like this:
* All decorators conform to the same interface of the object they are
decorating.
* Methods follow this pattern: (In C++)
    type CMyDecorator::SomeMethod(args)
    {
        // Do some additional stuff
        return mObjectBeingDecorated.SomeMethod(args);
    }

The end result is you can add functionality to methods of an object at runtime.

Hope that helps,

-Corey O'Connor

On 9/15/05, David Baelde <david.baelde@gmail.com> wrote:
> Hi list,
> 
> We're getting crazy with some design problem. We need to design a
> buffer object and be able to extend it with some features
> (lexing,color highlighting... yes we're working on an editor). Here's
> the problem.
> 
> I'd like to have a class (or function) for every extension. For
> example be able to write
> new parsed (new lexed (new basic)). I.e. I would need the class:
> 
> class lexed buf =
> object inherit buf method get_token = ... end
> 
> It doesn't work cause inheritance is only from classes, not objects.
> But I want buf to be of any class (any super-class of buffer actually)
> but I don't want to coerce buf to type buffer, cause I want to keep
> extra methods if any were added.
> 
> I'd like to know if there's any simple example of why
> object-inheritance is forbidden, and if any of you have an idea for
> that problem..
> 
> Thanks.
> --
> David
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 


-- 
-Corey O'Connor

Re: [Caml-list] Heritage

[David Baelde]

I don't think the decorator pattern fullfills my needs, cause it does
not allow you to end up with one object having an added method from
one decorator and an other one from a different decorator. You can
compose decorators, but you'll only see the methods of the last one.

Thanks anyway.
-- 
David

Re: [Caml-list] Heritage

[Corey O'Connor]

On 9/15/05, David Baelde <david.baelde@gmail.com> wrote:
> I don't think the decorator pattern fullfills my needs, cause it does
> not allow you to end up with one object having an added method from
> one decorator and an other one from a different decorator. You can
> compose decorators, but you'll only see the methods of the last one.

I don't follow your argument why a Decorator would not work. What do
you mean by "the last one"?
(Again sub-par C++ typed directly in Mail)

class IBuffer
{
public:
	virtual void SomeMethod() = 0;
}

class CBuffer : public IBuffer
{
public:
	void SomeMethod() = { //... Whatever... }
};

class CDiscoBufferDecorator : public IBuffer
{
	IBuffer* mDecorated;
	
public:
	CDiscoBufferDecorator(IBuffer* inBuffer) : mDecorated(inBuffer) {}
	
	void SomeMethod() = 
	{
		std::cout << "Disco!" << endl;
		mDecorated->SomeMethod();
	}
}

class CFancyBufferDecorator : public IBuffer
{
	IBuffer* mDecorated;
	
public:
	CFancyBufferDecorator(IBuffer* inBuffer) : mDecorated(inBuffer) {}
	
	void SomeMethod() = 
	{
		std::cout << "Not really that fancy... " << endl;
		mDecorated->SomeMethod();
	}
}

IBuffer* theFancyBuffer = new CFancyBufferDecorator(new CBuffer);
IBuffer* theDiscoBuffer = new CDiscoBufferDecorator(new CBuffer);
IBuffer* theDancyDiscoBuffer = new CFancyBufferDecorator(theDiscoBuffer);

Three instances that all conform to the Buffer interface but with
different "decorations".
So there would be one object with one decorator (theFancyBuffer) and
another object with another decorator (theDiscoBuffer).

Isn't that behavior what you want?

-- 
-Corey O'Connor

Re: [Caml-list] Heritage

[skaller]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

On Thu, 2005-09-15 at 15:15 -0700, Corey O'Connor wrote:
> On 9/15/05, David Baelde <david.baelde@gmail.com> wrote:
> > I don't think the decorator pattern fullfills my needs, cause it does
> > not allow you to end up with one object having an added method from
> > one decorator and an other one from a different decorator. You can
> > compose decorators, but you'll only see the methods of the last one.

> class IBuffer
> {
> public:
> 	virtual void SomeMethod() = 0;
> }

WTF does the C++ community have the audacity .. or is it
just plain ignorance .. to rename what is nothing
more than a fold ..

.. except of course .. it is considerably *less* functionality,
since you can make a list of the functions
to fold over the object in many orders dynamically,
without needing any class crud, which names types
that don't exist.

-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Heritage

[Corey O'Connor]

On 9/15/05, skaller <skaller@users.sourceforge.net> wrote:
> WTF does the C++ community have the audacity .. or is it
> just plain ignorance .. to rename what is nothing
> more than a fold ..

Well, for some it's ignorance. However, I don't audacity has anything
to do with it. Thinking of OO techniques to extend functionality at
runtime for methods of a type is easier to think about for most. 
Though, I think a decorator more closely matches a module functor*.
However, if somebody is asking for help with an OO question, I'll give
an OO answer. ;-)

-- 
-Corey O'Connor

* I say "module functor" because in the C++ world a "functor" stands
for "function object" and confusing the two would be, well, confusing.
Maybe just for me tho.