Re^2: Better Inside-Out Objects :)

OK, I'll grant that I don't get the compile-time attribute safety and thus this isn't really "inside-out" in the full sense of the word. However, it's not an XY problem because the specific problems that I deal with over and over again are twofold: one, people constantly violate encapsulation. Two, the compile-time safety isn't much of an issue for me because I write enough tests for my code (caveat: when working in a sane environment), that I catch the bugs up front.

Further, the syntax of various inside-out object modules is just frickin' painful to me and I've used them and tried to evangelize them! When I try to get others to used them, I invariably get a huge amount of resistance along the lines of "blessed hashes are good enough for me". Regardless of whether or not it's rational, when you're on a team of five programmers and the other four agree with the concept but flat-out reject the implementations, you have to know when to cut your losses.

For me, it's the encapsulation which is my biggest concern. If I can provide a way that programmers won't violate encapsulation but it's very easy for to migrate to (with sane code, nothing breaks!), then I've solved the exact problem I'm faced with. If you're trying to solve a different problem, then the XY problem applies.

Cheers,
Ovid

New address of my CGI Course.

Comment on Re^2: Better Inside-Out Objects :)

Replies are listed 'Best First'.
Re^3: Better Inside-Out Objects :) by xdg (Monsignor) on Oct 06, 2006 at 22:06 UTC
the syntax of various inside-out object modules is just frickin' painful to me So, specifically, the whole "id $self" stuff? I can see that, though I suspect it's all about what people are used to seeing. I think the overload-like-a-hash approach will be problematic in the long run because the apparent simplicity masks significant complexity. Serialization is probably the first place this will really pop up and fail to behave like people expect. What happens when someone tries to throw one of these objects at `Data::Dumper` et al? What happens when someone tries to create an object on the fly by loading data into a hash reference manually and then blessing it into an object? (E.g. loading YAML or other external config data?) `my $ref = { foo => 23, bar => 42, }; bless $ref, "Bar";` [download] -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply] [d/l] [select]
Re^4: Better Inside-Out Objects :) by ikegami (Patriarch) on Oct 06, 2006 at 22:36 UTC
What happens when someone tries to throw one of these objects at Data::Dumper et al? That's a problem with Inside-Out Objects in general. What happens when someone tries to create an object on the fly by loading data into a hash reference manually and then blessing it into an object? They ought to be shot. Constructors (incl cloning and deserializing constructors) exist for a reason. You can't expect to clone an object by copying it's bytes or it's fields.	[reply]
Re^5: Better Inside-Out Objects :) by xdg (Monsignor) on Oct 07, 2006 at 03:25 UTC
That's a problem with Inside-Out Objects For Data::Dumper, yes, because its OO approach is broken. Not so for Storable. I was speaking generically. You can't expect to clone an object by copying it's bytes or it's fields. Ditto for changing its properties by directly accessing its hash, which is why this is a mess. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]


The stupid question is the question not asked
	PerlMonks