Make as3commons.logging.setup.target integration easier to extend.

[GoogleCodeExporter]

So recently I decided to abandon my own logging library in favour of 
as3commons, and rather extend the good work you've already done. 

While I appreciate most of the things I don't agree with are stylistic design 
decisions, I'm struggling to understand why you choose to make some setup 
targets final. For instance, the MonsterDebugger3TraceTarget Class. Trying to 
change simple formatting is now impossible without directly editing source code 
and compiling your own SWC, or creating an entirely new target with largely 
duplicated code (What I went with in the end). Additionally it would be useful 
if you could make the private vars protected to provide access in the 
subclasses. The whole library has such a beautifully flexible design, I see no 
need to throw that flexibility at the last moment just to maintain some 
idealistic design purity.

Anyway, it's not a show stopper to implement your own targets, but just 
throwing in two cents. I'm sure there are other higher priorities but this was 
something I ran into that I thought was odd. 

Original issue reported on code.google.com by BurntPro...@gmail.com on 5 Sep 2011 at 1:34

[GoogleCodeExporter]

Also, far less important - but it would be nice if the Default Format strings 
etc in classes like trace target weren't const but rather vars. This way I 
could wrap it up in my own class and set it once in my own configuration and 
forget about it rather than having to look up the expected format of the magic 
string every single time I implement it in a project. 

Again, a subtlety, but one of those ways that practicality gets lost in design. 

/Thinking aloud more than anything. I know you can pass in your own format in 
the constructor.

Original comment by BurntPro...@gmail.com on 5 Sep 2011 at 1:49

[GoogleCodeExporter]

Any "non-final" class can be used for extending (like you wanted to). The 
extending would mean for us (as framework developers) that we have to make sure 
that the internal API too doesn't change.

Also in the case of the targets, almost 90% of the code are implementation 
specific. The Monsterdebugger4Target is a class with 40 lines of code (almost 
nothing). I am curious what you would want to reuse for what kind of target.

Original comment by mastakan...@gmail.com on 5 Sep 2011 at 2:04

[GoogleCodeExporter]

Well let me say I'd be surprised if you actually implemented these changes, but 
it I thought it would be worth highlighting considerations you might not 
thought of. So lets get specific:

MonsterDebugger3TraceTarget - final, completely not extendable
MonsterDebugger3LogTarget - not final. 

So what would I want to change? Well monster debugger takes a label parameter 
which isn't being used, well I decided to use it. Also I decided it would be 
more useful to instantiate the connection to monster debugger inside the target 
as a convenience. So all in all this is a very small corner of the entire 
library and I commend you for your work, and yes, the classes are trivial to 
implement, in fact I've already implemented my own in the time since I wrote 
the first messages. I also have no doubts that if you implement these changes 
it wouldn't make a significant difference to most people.  

That however isn't really the point I was trying to make. More specifically we 
have a class that has almost no bearing on the core framework declared final, 
when a class that is almost completely analogous isn't. That's a bit weird. As 
is the notion I would break anything by changing two lines of an implementation 
not related to the core framework, and now have to copy paste 40 lines of code? 
Please don't get offended or mired in specifics, there is a reason I'm using it 
in the first place. :) 

But there is however a reason I haven't used it before now, namely because I 
had the sense that while things are beautifully designed from a purely OOP 
structure, there is a certain arrogance about how people use it, and how to 
make that as easy as possible. Though seeing something like DIRECT_LOGGER and 
simple debug functionality is definitely good progress, which together with the 
extensive coverage of log targets was actually what convinced me to take the 
plunge and start using the as3commons above my own implementation. Okay I've 
drifted onto design philosophy, which this isn't the forum for. 
-that guy who adds two cents and lets the other do the heavy lifting.

Original comment by BurntPro...@gmail.com on 5 Sep 2011 at 3:37

[GoogleCodeExporter]

You copied 40 lines because you actually implemented the same thing that 
already exists, but is not good enough from your point of view.

I am wondering how you implemented the MD-Target. I assume it can be made 
genuinely better than it is in my implementation. That would make life not just 
more comfortable for you, but for anyone who uses the framework.

To the main discussion: From my point of view, that the class is final classes 
didn't hinder you a lot. Logging is built for high-performance and "final" 
certainly helps. To me: "easier to extend" needs to have a purpose. Up till now 
I have not found a good use case yet. Your use case was more a improvement 
request for MD-target to me. I extracted the feature request as issue 
http://code.google.com/p/as3-commons/issues/detail?id=77 and close this feature 
request since its pretty unspecific (even though very helpful!).

Thank you for pointing out that the MD-LogTarget is not final, a mistake I was 
careless enough to release(will have to think about what to do with that one a 
little, maybe just fix&release :-p).

You are right, issue-reports are not the best place for architectural 
discussions. However, I am usually very open to this sort of discussion, just 
use the google groups to continue, for any topic you want. 
http://groups.google.com/group/as3-commons-developers Also don't hesitate to 
invite me for chat in Google+ or talk to me via Skype (mastakaneda).

Thank you for the nice response to my recent changes, it is nice to see that my 
work does have an effect.

Original comment by mastakan...@gmail.com on 5 Sep 2011 at 4:35

• Changed state: Invalid
• Added labels: Type-Enhancement
• Removed labels: Type-Defect