It doesn't surprise me at all that you're finding objects to be very
useful, because they are!
Unfortunately, it seems like your dislike of OOP has left you a bit unsure
about how to "do it right".
Continue down this road and you'll end up in one of the places where the
people who really gave it some thought ended up already, perhaps some
research into the matter would help chart a course to somewhere useful.
I think one useful concept that Scala has brought to the masses is the idea
of "traits" - that is, a way to compose objects. A trait expresses
constraints on an object like an interface, but also provides functionality
that satisfies constraints. This allows one to compose the same traits
together in different ways to get different objects.
Scala also maintains a distinction between classes, instances, and
singleton objects in a somewhat clever way. I think the idea of a class is
useful in that the compiler can do a lot of "desugaring" and save on
boilerplate.
Of course, one might also argue that your use of objects instead of type
classes points to a failure of your type class system. Surely you can do
whatever you are doing with objects using type classes? Perhaps there's
still hope to fix type classes and toss the object system.
On Wed, Nov 14, 2012 at 12:24 AM, john skaller <
skal...@users.sourceforge.net> wrote:
> Because of the way objects work, we can do inheritance with delegation.
> Here's an example. First the base:
>
> /////////////
> interface A[T] {
> print : 1 -> 0;
> get: 1 -> list[T];
> }
>
> object fred[T] (x:list[T]) implements A[T] =
> {
> method proc print () { println$ x; }
> method fun get () => x;
> }
>
> var lst = list$ 1,2,3;
> var a = fred lst;
>
> a.print();
> println$ a.get();
> ////////////////
>
> By the way note that the object type appears polymorphic,
> as does the factory function fred.
>
> The actual object constructed isn't, its an A[int].
> In general, felix cannot handle polymorphic values.
>
> So now here's something that works kind of like
> inheritance:
>
> ////////////////
> interface B[T] extends A[T] { pprint: 1 -> 0; }
>
> object joe[T] (a : A[T]) implements B[T] = {
> method proc print () { a.print(); }
> method fun get () => a.get();
> method proc pprint () { print "Hello "; a.print(); }
> }
>
> var b = joe a;
> b.print();
> b.pprint();
> println$ b.get();
> ////////////////
>
> Here, we used delegation to "emulate" inheriting methods.
> The actual interface B[T] is and extension.
>
> Note that with this technique "overriding" a base class method
> is a non-sequitur i.e. its a nonsense idea, since we can either
> delegate explicitly as shown, or, we can define a new method,
> which is equivalent to inheriting the method or overriding it.
>
> Note also we have inherited from an object NOT a class.
> Its an actual, separately allocated object which we might
> copy or not (if the factory function use "var" we could
> guarantee a copy by eager evaluation). However it
> doesn't matter two hoots or more because we have
> only copied the record of closures NOT the state ..
>
> Felix "objects" are more dynamic and more object like than
> those in C++ or Java. Ttechnically .. the state associated
> with an object is separate from the object!
>
> The vtable, if you like, is the actual object and is linked
> to the state, in C++ its the other way around:
> the state is linked to the vtable.
>
>
> So what if you wanted to encapsulate the state? So it couldn't perhaps
> be externally modified?
>
> Easy!!
>
> object hilda[T] (lst:list[T]) implements B[T] = {
> var a = fred lst;
> ...
> }
>
> Thats really cool (hey I only just thought of that!)
> Now the base state object is a local variable of the factory
> function as so is hidden: the state is protected now.
>
> So what I think we need to "fool"** Java programmers into thinking we
> have OO is a simple syntax for method delegation. Any suggestions
> how to encode the above technique in a slightly nicer syntax?
>
> ** Whilst I usually derive Java and OO I am not meaning to do so
> in this case. Heck, I implemented objects and interfaces "a la Java"
> just for fun to show how powerful Felix was .. I didn't expect it would
> be all that useful, just a curiosity.
>
> But now, I'm using it extensively for implementing plugins
> and breaking the webserver and documentation tools down into
> small separately compiled units.
>
> In fact, I was thinking "why not add state to classes" which would
> give us Ocaml modules (by this I mean to allow value parameters
> to classes, such as "hash function" is a parameter to Hashtables).
> But actually .. objects subsume this .. I just didn't realise they
> could be polymorphic :)
>
>
> --
> john skaller
> skal...@users.sourceforge.net
> http://felix-lang.org
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Felix Language" group.
> To post to this group, send email to felix-langu...@googlegroups.com.
> To unsubscribe from this group, send email to
> felix-language+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/felix-language?hl=en.
>
>
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
