Back to Questions
1.4k
views9
comments
How to trigger events in sub-classes without Protected attribute?
f#

Hi

I've just become familiar with Events in F# and by and large I like the way that things work especially combined with pipelining and the Observable functions. However there is one problem I'm having with the design of class hierarchies and the triggering of events.

Normally in C# if I have an event defined in a base class it is private, but I create a protected member function that can be used to trigger the event from one of the subclasses. This can't be done in F# since it doesn't provide for Protected members. So I was left with the choice of making the Trigger method public on the base class (which is a bad idea). Or simply not having the event defined in the base class, and instead making separate events in the subclasses.

I decided to go the route of separate events in the subclasses. But this is totally sub-optimal because events defined in the sub-class are naturally only able to provide info about what's going on in the subclass and not what's happening in the parent.

Is there some better way of doing this in F#?

Derek

.

You could always implement this part of your code in C# to get the auto-magic scoping you want and call from F#. Or you could wrap a private event and provide a member fn that only allow subclasses to add observers, as they can't trigger the event if they don't have access to it.

Or just do what some prefer to do anyway - just make the event/delgate/interface public and put an XML comment on it saying that the event is normally triggered internally only and not to call it unless you really mean it, and leave it up to the caller to be mature enough to decide whether they should trigger it or not. (There are dozens of times some API designer has seen fit to make something sealed/final, private, opaque, etc., when if you're writing a testing harness or something else that makes the API a PITA or downright impossible to use without extreme measures like reflection or worse.)

By on 11/24/2010 9:33 AM ()

Well I am working on a project now that is just for me so I can obviously make things public if I wanted to, and on occasion I've taken the easy route when I've run into roadblocks with F#. However I'm really trying to force myself to do things in the functional style, sticking with immutability etc.

I've made a lot of progress with F#, but now that I have more of a real world application I'm running into walls like this occasionally. So when I see something that looks like it will be a real shortcoming when developing large scale systems I like to ask around and see if I'm misunderstanding something about the language design choices. In this case I just don't get why protected was poo-pooed.

Another thing I'm kinda struggling with is interfaces and the fact that you have to explicitly cast back to the interface before invoking functions on the object that implements it. While this doesn't expose the same kind of risk that the lack of protected does, it makes the code unwieldy and verbose. I've read several of the arguments about why the explicit cast is better, but remain unconvinced.

Derek

By on 11/25/2010 1:06 AM ()

An easy (but verbose) way to circumvent the problem with the interface is to implement a member-function (with the same name or whatever you fell like) and just use this function in the interface-implementation.

By on 11/25/2010 4:02 AM ()

I'm not quite sure what you mean here, could you post an example?

Thanks, Derek

By on 11/25/2010 8:36 AM ()

I'm not quite sure what you mean here, could you post an example?

Thanks, Derek

Hi,

sorry english is not my first language so maybe I got some issues with making my ideas clear. So what exactly is unclear?

I guess the last rants should be clear to everyone who ever used the F# project-system inside VS. And the stuff with static declarations and constructors inside a interface should be as well.

So I guess it's the first stuff.

Lets say you want to implement some kind of arithmetic interface (lets make it simple and stick to addition for now) - you can do something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

type IAddition<'a> =
    abstract Add : 'a*'a -> 'a
    abstract Zero : 'a with get
    
type MyInt(i) =
    member m.Value = i
    interface IAddition<MyInt> with
        member i.Zero = new MyInt(0)
        member i.Add (a,b) = new MyInt (a.Value + b.Value)
        
module Tests =
    let x = new MyInt(5)
    let y = new MyInt(6)
    let z = (x :> IAddition<_>).Add(x,y)

Isn't that ugly? Without compiler support to nicely translate the Add it's unusable. And even worse - I have to make the interface generic.

What i'd like to see (and use) is something like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

type IAddition as A =
    abstract static Zero : A with get
    abstract static Inv : A -> A
    abstract static (+) : A*A -> A
    default (+) (a,b) = a - (Inv b)
    abstract static (-) : A*A -> A
    default (-) (a,b) = a + (Inv b)

type MyInt(i) =
    member m.Value = i
    interface IAddition with
        static member Zero = new MyInt(0)
        static member Inv a = new MyInt (- a.Value)
        static member (+) (a,b) = new MyInt (a.Value + b.Value)

And languages like Haskel provide something very similiar (and even more powerful) than this - you can even watch some lectures on channel 9 on "Type Classes" and der uses.

I don't know if they ever manage to give us full TC support but even for day-to-day development I'm graving for something easy like this

1
2
3
4

 

class Foo<tX> where tX : new(int initValue)
By on 11/25/2010 9:39 PM ()

I have to disagree.

Making something public only to allow test to be written in s simple way is IMHO against everything encapsulation stands for.

For me the best thing of OO design is that I don't have to comment every possible missuse of some function by just making those not accessible from the outside.

TDD is fine but in most interesting cases (those cases where you have indeed to think to make some code work) it just fails (try writing - lets say a sorting - algorithm with TDD - won't work).

To stumple back to the main question: yeah it's a shame that those simple thinks are somewhat hard in F# and it's mostly those thinks (together with no good refactoring, designer or tool support) that makes me try to do more things in F# but end using C# anyway.

F# is real fun and I love to use it but as we don't seem to get mor FP support in the CLR in the near future and as C# and VB will *lend* the most usefull feature (async) and will even make it better (IMHO) I fear that F# will be less and less a option .... the geek in me cries out indeed (if I don't get any real support I can do my fun and geek stuff in Haskel instead)

Well sorry for getting real OP but I just felt like saying this stuf.

By on 11/24/2010 9:31 PM ()

Two different topics...

>Making something public only to allow test to be written

I didn't say that was the only reason - and making something public was only one out of three choices I posted - there are probably more. I just happen to like the Python-esque approach of exposing more, and having conventions such as .thisIsPublic and ._thisIsMorePrivate, etc.

Now, I would <i>much rather <i>have some sort of capability-based architecture with direct support for generic user-defined access levels rather than just the coarse-grained OO-centric access modifiers we have now. That way you could define API levels for Mort, Elivis and Einstein, for Testers, Sandboxed in the browser or not, etc., some of which would require compiler switches or access tokens - but I haven't seen this on the .Net radar. You could do this failry easily at a tooling level (with less safety) with [Attributes] in code that IDE would look at to filter out methods not supported by the current set of filter tokens or access-level. If the OP is writing an API for to be used by thousands of programmers of varying skill then I agree that the public solution is not a good idea -- but if he's writing some classes for himself or for a few programmers, I don't think you really need to spend many cycles on implementing perfect design patterns, but rather solving the problem at hand. > we don't seem to get mor FP support in the CLR Tooling support I agree with 100% (though F# makes this hard than C#), but in what way is the CLR not supporting F# to the degree that you'd wish? [Looks like based on some posting titles you're mostly concerned with immutability?]

By on 11/24/2010 10:29 PM ()

> we don't seem to get mor FP support in the CLR

Tooling support I agree with 100% (though F# makes this hard than C#), but in what way is the CLR not supporting F# to the degree that you'd wish? [Looks like based on some posting titles you're mostly concerned with immutability?]

Hi,

well there are a couple of thinks - real checked immutability is a minor think. What I really like to see (for C# too) are type-classes or more powerful interfaces (for example we can't even do a simple think like a arithmetic-interface, because we can't define static members, we can't refer to the type that implements the interface and we certainly can't "Mix"; more: I can say "new" to indicate that I want a constructor but behold it will only be a () -> xyz but what I want is to tell the stupid think what signature the ctor should have (ISerializable is a good example - you have to remember to implement the right ctor because the interface certainly don't indicate it's need).

Then: I don't want to queue the files in the right order. I want cross/mutual referenzes (type ... and ...) across files. I want good subfolder support, etc.

As it is you can use F# to prototype short libs or some little APIs but that's it - I really tried hard but it's a pain to write your buisiness logic or even some heavier helper-Dll in F# so I allways end up using C# with all it's nice support - and I really hate it.

But all we here is some (intersting) new thing with data and F# - that is intersting from a sci. standpoint but just don't make F# for the day-to-day development better.

By on 11/25/2010 4:16 AM ()

>> we don't seem to get mor FP support in the CLR
> ...

Ok, so it's not the "CLR" you are addressing, but the F# language design and the tools support.

I agree that type-class are cool, but I'm not sure if they're on the radar or not. An actual active meta-class hierarchy, in which a "static" in a class is really putting a non-static in the meta-class (which would support inher. of c'tors, etc.) would be cool or may be able to address some issues in a more OO-way and would be applicable to all .Net languages.

>so I allways end up using C# with all it's nice support - and I really hate it

Yeah, I sometimes write the "scaffolding" in C# for tooling support, and the "guts" in F# for such cases.

By on 11/26/2010 8:38 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper