June 03, 2007

New Blog

Writing about web page http://www.aboutcode.net/

I have started a new blog http://www.aboutcode.net/

After I graduate, this blog will be discontinued. I’ll try to archive the old posts somewhere soon.


March 26, 2007

Pie v1.3.3 released

The new version of Pie (new name still pending) is out.
Download now
Uninstall any previous version first from Control Panel > Add or Remove Programs.

Report any bugs and suggest ideas to andrew@equin.co.uk or leave a comment here.
For the power users out there, the system event log will contain any errors that occurred when reporting it’s helpful to include them.

Thanks!


Podcasts from IE7

My podcast viewer currently runs standalone and as a plug-in for Windows Media Player.
How would people prefer to use it? I would love to make it a ClickOnce application that can be installed without being admin. This however would limit the ability to install the WMP plug-in. On the plus side, you receive automatic updates.
I am investigating ways to make the app ClickOnce install and then register the plug-in later. The problem is that the uninstall would not remove the plug-in for you.

In addition, I need a funky name for the app. PIE is a bit abstract and confusing with other products.
I quite like “PodBouncer”, but I’m open to options. The only real constraint is that the .com domain needs to exist.


equin.co.uk temporarily offline

Due to hard failure at the hosting company I use, my domain equin.co.uk is offline.
This means all my email is probably not working either. I’m as annoyed as you are, but these things do happen! They are restoring from back-ups at the moment. I hope everything is back to normal soon.


March 23, 2007

Prettier Pie

Follow-up to PIE! Podcasts from Internet Explorer from codeMonkey.Weblog();

OK, so the first HTML UI was a bit of a quickie…
I’ve made it a bit nicer now. In future versions you will be able to set your own style sheet as well to completely customise it.

Please send me your thoughts, ideas, comments, etc.


March 22, 2007

PIE! Podcasts from Internet Explorer

Follow-up to Updated Podcasts in Media Player Plugin from codeMonkey.Weblog();

After numerous and continued requests via this blog for a working version of the Windows Media Player podcast viewer plugin, I finally found the time to make it!

I have gone for the name Pie: Podcasts from Internet Explorer
Download it now!

Pie runs as an windows application or as a plug-in for Windows Media Player.
Pie gets the podcasts that have been downloaded by Internet Explorer 7’s feed engine.
You can expand items to read the show notes and click the show title to play.
The playlist button creates and plays a playlist of either all podcasts or just those not yet played.
In addition, an auto-playlist is added to the Windows Media Player library that will have all the podcasts. This is useful if you want to sync them to your MP3 player.
Main Screen
Windows Media Player Plug-in


March 14, 2007

Overriding implementation class members

Follow-up to Implementation Classes Again from codeMonkey.Weblog();

On the way home I thought of a way to override implementation class members in the user class.

class User
  use SomeImpl for IFooBar

  [OverrideImpl(IFooBar)] private SomeMethod() : void
    // specialized code...

class SomeImpl : IFooBar
  public virtual SomeMethod() : void
    // Normal code

The macro can translate this into “real” code by creating a new class inside User that inherits from the implementation class. We override the virtual method and make call to the User method.

The partial expansion then looks like this:

class User
  use SomeImpl_User_Overrides for IFooBar

  private SomeMethod() : void
    // Specialized code

  class SomeImpl_User_Overrides : SomeImpl
    private _user : User
    public this(user : User)
      _user = user

    public override SomeMethod()
      _user.SomeMethod()

So then we use the specialized class as the implementation.

This approach will also work for abstract methods defined in the implementation class that require implementation.


Implementation Classes Again

I’ve been thinking more about traits and implementation classes in OOP.
I put together a quick program in Nemerle to demonstrate the ideas I’m playing with.

I defined a class that implements System.ComponentModel.IEditableObject. It takes a “user” object as a parameter and implements a simple stack based state saver. BeginEdit copies all the fields of the user, pushing them onto the stack. CancelEdit can then restore state by popping the stack and setting the fields back to those saved values. EndEdit simply pops the stack leaving the current values in place.

    class EditableObject[T] : IEditableObject
        private _states : Stack[Dictionary[FieldInfo, object]] = Stack()
        private _user : T

        // We only take the reflection performance hit once per type T.
        private static _fields : array[FieldInfo]
        static this()
            _fields = typeof(T).GetFields(BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance)

        public this(user : T)
            _user = user

        public BeginEdit() : void
            _states.Push(CopyState())

        public EndEdit() : void
            if (_states.Count > 0)
                _ = _states.Pop() // Discard top of stack
            else
                throw InvalidOperationException()

        public CancelEdit() : void
            if (_states.Count > 0)
                RestoreState(_states.Pop())
            else
                throw InvalidOperationException()

        private CopyState() : Dictionary[FieldInfo, object]
            def dictionary = Dictionary()
            foreach (f in _fields)
                dictionary[f] = f.GetValue(_user)
            dictionary

        private RestoreState(previous : Dictionary[FieldInfo, object]) : void
            foreach (f in _fields)
                f.SetValue(_user, previous[f])

I now want to use this “implementation” class in many different classes. I do not want to inherit from this class directly. Trying to create an abstract base class purely to stuff lots of different implementation details together is just plain ugly too.
So I used the Nemerle ProxyPublicMembers macro.

    class Person : IEditableObject
        [ProxyPublicMembers] _editable : EditableObject[Person] = EditableObject(this)

        [Accessor(flags=WantSetter)] mutable _firstName : string
        [Accessor(flags=WantSetter)] mutable _surname : string

        public this(firstName : string, surname : string)
            _firstName = firstName
            _surname = surname

        public override ToString() : string
            $"$FirstName $Surname"

With the single line:
[ProxyPublicMembers] _editable : EditableObject[Person] = EditableObject(this)
the three public methods BeginEdit, CancelEdit, EndEdit are inserted into Person and they simply call the respective methods on the _editable instance field.

A simple test of the code is:

    static class Program
        static Main() : void
            def p1 = Person("Andrew", "Davey")
            Console.WriteLine(p1)

            p1.BeginEdit()
            p1.FirstName = "Foo" 
            Console.WriteLine(p1)
            p1.CancelEdit()
            Console.WriteLine(p1)

            p1.BeginEdit()
            p1.Surname = "Smith" 
            p1.EndEdit()
            Console.WriteLine(p1)

Outputting:

Andrew Davey
Foo Davey
Andrew Davey
Andrew Smith

One of the advantages of this implementation class approach is the ability to store both instance and static state. The EditableObject only takes the reflection performance hit to get a type’s fields once. The user class never has to know about this state at all.

It would also be possible to enable a form of “overriding” by the user class. Perhaps it needs a special way to save and restore state. We just need a way to tell the implementation class to call the user to do something, rather than doing it itself. Delegates could be passed to the implementation class upon construction. Or perhaps a more declarative approach could be taken by marking “override” methods in a user class with an attribute.

[OverrideImplementation(EditableObject)] private CopyState() : Dictionary[FieldInfo, object]
  // do stuff here

We would just require some macro trickery to get this working I reckon.

As it stands the standard ProxyPublicMethods macro in Nemerle enables an excellent approach to modelling problems in clean OO style. I think an additional macro to tidy up the syntax would make things even nicer.

class Person
  uses EditableObject for IEditableObject

Maybe?


March 02, 2007

Multiple Interface Implementation via Proxy

Nemerle is like C# in that it only has single implementation inheritance and multiple interface inheritance. However when modelling business problems it would be beneficial to have multiple implementation inheritance to allow for better code reuse and modularisation.
For example, consider a PurchaseOrder object. We would like to add rich UI data binding functionality and undo/redo operations to it. The .NET framework contains a number of interfaces that should be implemented to achieve these goals. IEditableObject has methods BeginEdit, EndEdit and CancelEdit. INotifyPropertyChanged has an event PropertyChanged. The implementation of these is fairly standard so we do not want to write it in each class. In C#, we would usually make some kind of abstract base class that implements the interfaces and then inherit our real business classes from that.
Whilst this approach is fine for simple object models, things get a lot more difficult when not all business classes require all interfaces. Maybe some are read-only; maybe others have special auditing requirements. We end up creating many strange abstract base classes that implement different subsets of functionality. This inevitably leads to repeated code and a maintenance nightmare.
If we step back, we realise that we are actually abusing inheritance as an attempt to reduce code repetition. A better approach would be to have implementations of single interfaces as single classes that are then pulled together by the actual business classes. The business classes are then in charge of what implementations they require, rather than relying on a rather fragile base class.
The following Nemerle code demonstrates how this might work:

class PurchaseOrder : IEditableObject
    private _editableObject : IEditableObject
    public this()
        _editableObject = EditableObjectImplementation(this)
    public BeginEdit() : void
        _editableObject.BeginEdit()
    public EndEdit() : void
        _editableObject.EndEdit()
    public CancelEdit() : void
        _editableObject.CancelEdit()

The constructor creates and instance of some implementation class. Any calls to the interfaces methods are forwarded to the implementation class. Note that we provide the implementation class with the object that is using it. This allows the implementation class to do things like reflection to get all the private state to be saved.
Basically, we are implementing a form of the Proxy design pattern.
The above idea will work fine (even in C# and VB.NET), however it requires lots of “glue” code to be written. This is where Nemerle macros come in handy!
Imagine being able to write something like:

class PurchaseOrder \
    use EditableObjectImplemenation for IEditableObject \
    use NotifyPropChangedImpl for INotifyPropertyChanged
{
// Look! No glue code at all now!
}

The “use” macro would expand out to code that includes private instance fields and the glue code that calls those instances.
Of course, the macros have to be quite smart, but there are already working Proxy macros for Nemerle that just need enhancing to support events (they already do properties and methods I believe).
Other enhancements allow an implementation class to place demands on the class using it. An implementation of some interface ICircle could provide members like “Area”, “Circumference” and “Diameter” but require the using class to have a member “Radius”. The implementation class calls back into the using class to get Radius. It can then provide the various additional members using that value. This idea follows from the work done on Traits in OOP, the difference here is that implementation are not mixed into the using class at compile time. By keeping them outside, they can do useful things like have their own state.

The benefits of such infrastructure are:
  • Classes are more logically decomposed.
  • Classes are less fragile.
  • Maintenance is easier.
  • Testing business classes by providing stub implementation is easy.

February 26, 2007

Graph Vectorisation

Initial Network Vectorisation
I combined the junction detector with the line following algorithm. The result is a graph vectoriser! I still need to refine the algorithm so it only uses each junction exit once, but basically it works!

The rest of the week can now be spent building an interaction demo. :D


Google Ads

Search this blog

Most recent comments

  • I scratched my eye while i was holding some kind of plastic packaging.. Anyways the corner of the pl… by Ercan on this entry
  • About a year ago my contacts that i was wearing, i guess were fautly, because shortly after they wer… by Jon on this entry
  • I got shower gel in my eye 4 and a half days ago, and becasue i rubbed my eyes a lot, i have scratch… by Chris on this entry
  • This website may help http://www.webmd.com/eye–health/tc/Eye–Injuries–Home–Treatment by S on this entry
  • I somehow got dirt, or debris in my eye. The terrible pain sent me in a tailspin. I was afraid of sa… by Bobbi on this entry

Tags

December 2014

Mo Tu We Th Fr Sa Su
Nov |  Today  |
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31            

Galleries

Blog archive

Loading…
RSS2.0 Atom
Not signed in
Sign in

Powered by BlogBuilder
© MMXIV