I've been working with Yauheny on the Framework/Fortress port to C# and had a couple of questions that I was hoping to Avalon community could help answer.
1) In light of the recent discussion and clarification of the ROLE field that is currently used for Java based components, I wondered how people thought this should port over to the C# version. The reason I ask is, in the Java version, defining the ROLE in the interface (for example in Excalibur PoolManager) worked out great. In C# however, fields cannot be defined in interfaces, therefore that approach would be invalid. The closest solution would be to define a read-only property in the interface, but that would still require the interface implementer to define the correct value, which could potentially differ from implementer to implementer defeating the purpose of the ROLE. The other option would be instead of using ROLE, to just reference it by obj.GetType().FullName (similar to Object.class.getName()). While this works fine, and achieves the correct result, it would be a different approach from the Java version and so that is why I ask what the opinion of the group is. I didn't know if differing on some things is tolerable (obviously some things will differ but the use of both should be similar) or if we wanted to try and find a common mechanism for both sides.
We will be leveraging the .NET attributes to mark what name we want to look up our role with. The container will match the type with the lookup value. This is consistent with both Phoenix and Merlin, and represents the cleanest way of doing things.
2) I guess this one is more for Yauheny or Berin since they seem to have done most of the port so far. How exactly are you implementing the lifecycle management in the C# version? I saw that instead of defining the lifecycles as interfaces that components can implement they have been defined as delegates (or function pointers). I'm curious how this is supposed to work and how the container interfaces with the components. If someone could give me an example I would appreciate it since I'm trying to port some things that require the lifecycles.
Inspired by NUnit2, the current line of thinking is to use attributes to mark the lifecycle methods. For example instead of Startable.start(), a developer can define:
[AvalonStart]
public void comenzar() throws Exception {}Or instead of Configurable.configure(), a developer can declare it like this:
[AvalonConfigure]
public void configuracion( Configuration config ) throws ConfigurationException
{}The delegators make it easier to perform the lifecycle management once the component has been properly "parsed". This allows the developer the most freedom possible including coding with method names in their native tongue (I used Spanish above because I can at least know a couple words in that language).
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
