Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^3: Imagination greater than reality?

by sundialsvc4 (Abbot)
on Jul 11, 2017 at 20:17 UTC ( #1194864=note: print w/replies, xml ) Need Help??


in reply to Re^2: Imagination greater than reality?
in thread Imagination greater than reality?

I really don’t think that, in this case, I need to “let me write that for you.”   It should be quite self-evident that I am talking about some function which, given (at least) a state-code as its input, returns an instance of an object.   Any possible attempt by me to jimmy-up a code example would be utterly meaningless to whomever is actually going to act upon it, and also would be quite unnecessary.   (I prefer to assume that people who ask questions here, most especially when they speak as the OP did, actually know how to write Perl code and don’t need any further help from me.)

Likewise, I don’t think that I need to “prove” anything to my Seven Anonymous Downvoters.®   Just amuse yourselves by casting seven downvotes on this response, too, and Be Happy.™   (I can’t help but notice that you seven poor souls seem to view this now-obligatory exercise as a boundless wellspring of amusement, even after all these years.  Tell me, do all you really not have anything else to do with your time?   Just askin.’)

Meanwhile, I do believe that the OP had a question.

Architecturally speaking, what you very much want to do is to centralize the process of “producing an appropriate object instance,” so that the necessary logic occurs in one place in the application ... and so that it is surrounded by suspicious error-checks.   Even if “the appropriate solution” consists of the OP’s method or BrowserUK’s subsequent suggestion of require, you emphatically do not want that logic to appear “all over the source-code of the program.”   Instead, you want to implement your solution in exactly one place, and call it from everywhere else.

The code that instantiates any object, in any programming language, is very closely tied to the correct operation of the object itself.   Especially in a language such as Perl(5), which contains no compiler-provided notion of an object at all, this consideration should be treated very formally and carefully.   For instance, every object should be entitled to assume that its creation-time parameters have been checked.   (In Perl, it is much safer IMHO to do this before instantiating the object, rather than to do it in the constructor.)   In a language such as Perl, consolidating these duties into one sub is a very prudent move.

This “one implementation, in one place,” is also a very natural place to check for errors bugs, and once again I strongly recommend that you do so aggressively.   Throw an exception if something ... anything ... is wrong.   Thus, any piece of code anywhere in the program that finds itself holding an instance of an object which must have been created by this factory, therefore also knows that every one of the “suspicious tests” performed by that factory must have succeeded.   (If some value within the object is now found to be bogus, then the corruption must have occurred after the object was instantiated.)   These are enormous time-savers when debugging a production program.

  • Comment on Re^3: Imagination greater than reality?

Replies are listed 'Best First'.
Re^4: Imagination greater than reality?
by shmem (Chancellor) on Jul 11, 2017 at 23:29 UTC

    Nice piece, your post. Really nice. It accurately shows your position and skills (IMHO[WTF]). You are a consultant, not a coder. Would you be the latter, you'd have come up with something to just silence your critics. A small, succinct piece of code, just to tell them to STFU. You didn't, 'cause your are a consultant. That's fine, consultants are needed sometimes to get people out of their narrow view and be helped to soar eagle-like over the broad picture, whilst having, as an eagle has, a keen eye for the smallest details. But what happens here?

    Coder (random PerlMonk) : I have a problem implementing this algorithm considering X, Y and Z. The issue is here (points to code)
    Consultant (sundialsvc4): Problems with implementing algorithms are known since the times of the PDP11, mostly due to memory constraints and user boundaries... (blah, blah... disgressing) ...and the 31 bit integer of S390 later... Solaris 1 and management/coder interaction... (blah, blah, blather...)
    Coder: ok, got that. Have some solution? Any hint?
    Consultant: first, you should do a ORM design of your overall architecture and draw explicit Venn-diagrams for your database queries, because blah, blah, blather...
    Coder: -.-

    See? People come here to learn Perl. People stay here to teach perl, and to learn more perl. This is a site about real perl issues and real perl problems and real programming, and not a site for seeking advice of a consultant or giving advice as such. Sadly, not.

    Code examples are necessary, because: "There is no other way of teaching than by example, and if it so must be, as a bad one." (Einstein)

    ...every object should be entitled to assume that its creation-time parameters have been checked. (In Perl, it is much safer IMHO to do this before instantiating the object, rather than to do it in the constructor.)
    This, IMHO, is as wrong as wrong can be. It goes against Postel's Law. Soaring as a consultant eagle above the low levels of cranking out code, you should update your maps. Otherwise, your counsel is of no use at best, detrimetal at worst.

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
Re^4: Imagination greater than reality?
by jdporter (Canon) on Jul 11, 2017 at 21:51 UTC
    let me write that for you

    Wow, you could not have misunderstood the intent of my request more grotesquely.

Re^4: Imagination greater than reality?
by Anonymous Monk on Jul 11, 2017 at 20:36 UTC

    I really don’t think that, in this case, I need to “let me write that for you.” It should be quite self-evident that I am talking about some function which, given (at least) a state-code as its input, returns an instance of an object. Any possible attempt by me to jimmy-up a code example would be utterly meaningless to whomever is actually going to act upon it, and also would be quite unnecessary. (I prefer to assume that people who ask questions here, most especially when they speak as the OP did, actually know how to write Perl code and don’t need any further help from me.)

    Why would those people need your kind of non-answers? Bourne from years of not writing code?

    Utterly meaningless and quite unnecessary spam is spam, it is not help, its spam.

    Likewise, I don’t think that I need to “prove” anything ...

    Not that more evidence was needed, but its nice to get fresh evidence you can't write perl code because you dont know how

    If one was to judge your business company by your spams on here, it surely must stink like a sewer.

Re^4: Imagination greater than reality?
by Anonymous Monk on Jul 11, 2017 at 21:04 UTC
    apart from complete shit, you can't write anything, let alone code anything. You know Jack shit. You are a toxic individual, and the worst thing here.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1194864]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (8)
As of 2017-11-23 21:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In order to be able to say "I know Perl", you must have:













    Results (340 votes). Check out past polls.

    Notices?