caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Corey O'Connor" <coreyoconnor@gmail.com>
To: david.baelde@ens-lyon.org
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Heritage
Date: Thu, 15 Sep 2005 14:25:10 -0700	[thread overview]
Message-ID: <c1291235050915142543de09e0@mail.gmail.com> (raw)
In-Reply-To: <53c6559205091513486a10b481@mail.gmail.com>

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


  reply	other threads:[~2005-09-15 21:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-15 20:48 Heritage David Baelde
2005-09-15 21:25 ` Corey O'Connor [this message]
2005-09-15 22:01   ` [Caml-list] Heritage David Baelde
2005-09-15 22:15     ` Corey O'Connor
2005-09-15 22:38       ` skaller
2005-09-15 22:58         ` Corey O'Connor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1291235050915142543de09e0@mail.gmail.com \
    --to=coreyoconnor@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=david.baelde@ens-lyon.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).