Brett Ryan wrote: > @kir >>> Properties are a 1-to-1 relationship of a classes member and the state >>> it's representing, >>> >> which is a violation of encapsulation and promotes unnecessary couplings. >> > That 1-to-1 relationship is the encapsulation, and it's actually > promoting the point. > Not really... For instance, just yesterday I had a String property exposed in my bean/mbean that for internal efficiency I ended up keeping the original string (for the getter) but also producing a Set<String> and a Collection<String>. I certainly did /not/ want all this exposed in my bean/mbean's interface! This is an internal implementation detail that is currently the best performance balance, but may change over time. >> You need to make methods first class citizens and then you can implement >> closures properly. Exposing pointer is something we want to avoid IMHO. >> > To the casual C# programmer they wouldn't even know they were actually > using function pointers. The language takes care of > First class methods are roughly the same as delegates which are essentially the Java/C# equivalent of function pointers. >>> since stateless code can't really listen to events in the first place. >>> >> Why not? >> > Well you can, but more so why would you? Events are more suited to > something that is going to hang around for a while in a state-full > fashion. > There are plenty of good use cases for a stateless listener, but clearly UI's involve state no matter how you try to avoid it :-)
-- Jess Holle --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
