Re^2: Psychic Disconnect and Object Systems

This is, in my opinion as a result of my personal experience of using OO & of working with others OO, completely the wrong way to approach the problem.

I could not agree more. I've seen discussions on automatically generating reader and writer methods for state variables (in which languages I don't recall), and I join the chorus of those pointing out that this probably isn't a good thing to be doing. It just encourages making the state not encapsulated, and is no different t han just declaring all the fields public.

The right way--I know, I know. bear with me.--is to define the methods first. Ask yourself not: what do these objects contain? But rather: what do these objects need to do? ... The right way--again--is to write the code that will use the objects first.

For sure! I start with use-cases and from there describe the object user's view of the object. I've written full documentation before finalizing the underlying design of just how it manages to do all that.

It sounds like we are on the same page. So, how would you use Moose today? Certainly I can start by writing the methods, and plan that any internal state that I need to implement them are indeed internal implementation details. So how do you declare your has's to create per-instance storage, for internal use only?

Comment on Re^2: Psychic Disconnect and Object Systems Download Code

Replies are listed 'Best First'.
Re^3: Psychic Disconnect and Object Systems by BrowserUk (Patriarch) on Apr 18, 2011 at 02:35 UTC
So, how would you use Moose today? I probably wouldn't. Mouse maybe, but not Moose. Mostly because it carries a lot of complexity under the covers in order to provide features--like deep introspection--that I do not see the benefit of. And even though that complexity is hidden from me, I know it is still there and I must carry its overhead though I'll never benefit from it. And for the type of code I mostly write these days, that overhead is significant. So how do you declare your has's to create per-instance storage, for internal use only? As I understand it, if you use `is bare`, then you get no accessors and no warnings. I'm not into the bondage and discipline thing. Indeed, in part it was the complexity of the whole private/public/friend thing that caused me to arrive at a considerable distaste for C++. (There are other reasons also, but that was one.) So when I feel the need for OO in Perl, I'm perfectly happy to construct mine around blessed refs manually. With no attribute accessors at all--public or private. '_'s to indicate private methods are sufficient for my purposes. And initialisation done by the constructor from whatever form of input makes most sense. Eg. If the data that is used to initialise an object is read from an external source as text, then either that text gets passed to the constructor, or for mass instantiation, an open file handle. Declarative syntax is a nice to have, but only if it retains sufficient control to allow me to decide (and only pay for) those features I want/need. As I rarely write assessors for my attributes, I've never felt the burden of doing so, so don't need auto-generation. And As I only validate parameters when they transition the public/private boundary--not every time an attribute gets written--the use of declarative validation is also superfluous. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Psychic Disconnect and Object Systems
by BrowserUk (Patriarch) on Apr 18, 2011 at 02:35 UTC

So, how would you use Moose today?

I probably wouldn't. Mouse maybe, but not Moose. Mostly because it carries a lot of complexity under the covers in order to provide features--like deep introspection--that I do not see the benefit of.

And even though that complexity is hidden from me, I know it is still there and I must carry its overhead though I'll never benefit from it. And for the type of code I mostly write these days, that overhead is significant.

So how do you declare your has's to create per-instance storage, for internal use only?

As I understand it, if you use is bare, then you get no accessors and no warnings.

I'm not into the bondage and discipline thing. Indeed, in part it was the complexity of the whole private/public/friend thing that caused me to arrive at a considerable distaste for C++. (There are other reasons also, but that was one.) So when I feel the need for OO in Perl, I'm perfectly happy to construct mine around blessed refs manually.

With no attribute accessors at all--public or private. '_'s to indicate private methods are sufficient for my purposes. And initialisation done by the constructor from whatever form of input makes most sense. Eg. If the data that is used to initialise an object is read from an external source as text, then either that text gets passed to the constructor, or for mass instantiation, an open file handle.

Declarative syntax is a nice to have, but only if it retains sufficient control to allow me to decide (and only pay for) those features I want/need.

As I rarely write assessors for my attributes, I've never felt the burden of doing so, so don't need auto-generation. And As I only validate parameters when they transition the public/private boundary--not every time an attribute gets written--the use of declarative validation is also superfluous.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]
[d/l]