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.
03 Jun 2007 12:45
| 
Comments (0)
| 
Report a problem
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!
26 Mar 2007 23:33
| 
Tags: Coding Ie7 Pie Podcast
| Comments (1)
| Report a problem
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.
26 Mar 2007 22:29
| Tags: Coding Dotnet Podcasting Wmp
| Comments (1)
| Report a problem
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.
26 Mar 2007 16:24
| Tags: Domain Equin Offline
| Comments (0)
| Report a problem
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.
23 Mar 2007 02:47
| Tags: Coding Dotnet Ie7 Pie Podcasting Wmp
| Comments (1)
| Report a problem
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.
22 Mar 2007 22:31
| Tags: Coding Dotnet Ie7 Pie Podcasting Wmp
| Comments (16)
| Report a problem
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.
Please wait - comments are loading
class User
use SomeImpl for IFooBar
[OverrideImpl(IFooBar)] private SomeMethod() : void
// specialized code...
class SomeImpl : IFooBar
public virtual SomeMethod() : void
// Normal codeThe 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.
14 Mar 2007 15:11
| Tags: Coding Implementation Classes Nemerle OOP
| Comments (0)
| Report a problem
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 SmithOne 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 hereWe 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 IEditableObjectMaybe?
14 Mar 2007 12:27
| Tags: Coding Implementation Classes Nemerle OOP
| Comments (0)
| Report a problem
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.
02 Mar 2007 10:50
| Tags: Coding Macros Nemerle
| Comments (0)
| Report a problem
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
26 Feb 2007 22:38
| Tags: Project
| Comments (0)
| Report a problem
Loading…
