This is an archived low-energy page for bots and other anonmyous visitors.
Please sign up if you are a human and want to interact.
in reply to Re: VarStructor 1.0
in thread VarStructor 1.0
I agree with all this pretty much. I have to admit I wonder at wassercrats thinking on occassion. He doesnt seem to learn when the mule kicks other people, and its not even clear if he learns when the mule kicks him. I dont get this at all. Most people I know learn from other peoples mistakes. *shrug* Its his life I guess.
But I do have a nit: You said ^ (and, for that matter, $) are not special inside of character classes. which is wrong. ^ is special inside of char classes when the it is the first character of the char class. It cause the char class to be negated.
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
|
Re^3: VarStructor 1.0
by tkil (Monk) on May 04, 2004 at 11:55 UTC
|
^ is special inside of char classes
when the it
is the first character of the char class. It cause
the char class to be negated.
D'oh. Perfectly true, of course. Where's my brown
paper bag?
| [reply]
[d/l] |
|
|
I still haven't finished reviewing everything, but I wanted to thank you for reviewing my code in such depth. In Chatterbox I mentioned the things I'm going to look into, but I guess you already fixed those things in the code.
I'll just make a few points here:
I used to format my comments to a certain width, but that makes them more difficult to edit and artificially increases the line count, so I only format certain comment blocks that way, such as ones most likely of interest to others.
I'm going to put back much of my own style for less practical reasons than the comments--just because it's my style. I won't be using all those x modifiers and extra spaces, I'll change the indentation, etc.
You added variables, such as $out_vars and changed lots of other stuff without clearly indicating where the changes were made. I already wrote a mostly working script. I don't want to have to learn it all over again as if it's not mine, and I need to check the changes.
I like my parameter handling. It makes it easier on the programmer because he could add just the parameters he wants without extra commas. I see you did something with grep and shift that I can't figure out off hand (forgot how they work), but all I'll be changing is the "e:" and maybe "i:" indicators, maybe to "include:" and "exclude:", to avoid a file path from being confused for the second parameter.
In LinkStructor, I generally use upper case for variables that are not configurable by the user and This_Style for those derived from the interface, so shouting or not, I might continue doing that for consistency in my own little world.
I'm not afraid of saying "if you don't do it this way, my utility won't work," in some cases. It makes label and sub detection easier, and my rules aren't so unreasonable. The ability to omit and include those blocks when clearing or listing variables isn't offered in any other product as far as I know, so limitations aren't so bad, though I see you replaced my sub detection routine with your own. I guess I'll take a look at it and maybe use it.
You've come close to making the fears I expressed here come true: "One of the reasons I'd be reluctant to release a subroutine of my script as a Perl module is that it would probably be pounced upon and improved beyond recognition and beyond my ability to work with it any longer, and I wouldn't want to lose my first baby."
| [reply] |
|
|
I still haven't finished reviewing everything, but I
wanted to thank you for reviewing my code in such
depth.
You're welcome. Even with code where I disagree
with both the style and the purpose (nicely done!
:), I can still enjoy trying to figure out what
is going on.
The point here is that proper editor support can make
it easier to develop code that is then easier to read
as well as being nearly painless to develop and modify.
Code is read far more often than it is editted, so
taking a slight bit of extra pain is probably called for.
(Also, you can defer reformatting those comments until
you issue a point release, which would further reduce
your maintenance burden.)
I won't be using all those x modifiers and extra
spaces, I'll change the indentation, etc.
Well, the use of /x is generally a good
idea for regexes of any complexity at all — and
some of yours are doozies. The only down side to the
/x modifier is that whitespace has to be
specified explicitly.
So they are different variable names, and I can
see how you'd have to re-learn a routine after
that replacement. The advantage is one that you
have not been particularly receptive to: the use
of my variables. While they add to
the initial dose of code that has to be digested
when you read it at first — but that is offset
the the knowledge that, outside this one screen of
text, nothing can modify that variable.
Once fully understood, this freedom is liberating
to the point of being intoxicating.
(This resonates with the reason that I — and,
it seems, the majority of the Perl monks — find
your module to be distasteful to the point of being
dangerous. See the end of this response for more
on that, though.)
I like my parameter handling. It makes it easier
on the programmer because he could add just the
parameters he wants without extra commas.
One of the most fascinating tensions in Perl is that
between consistency and "do what I mean". Perl tries
very hard to fulfill the later, often at a cost to the
former. Which is fun and pleasant and (as the vibrant
community can attest), generally it works. But it is
not for nothing that this inconsistency has been
described as Perl's greatest strength and its
greatest weakness.
The easiest way to avoid any issues with this would
be to preface any post with exactly what you expect
us to do with it. If you look around our site,
you'll notice that posted code is often critiqued
(both in the large and in the small), modules to
replace or augment it are suggested, etc. If this is
not what you want, say so!
I think that you genuinely were trying to be helpful:
you have a tool that helps you get your job done, and
you wanted to share it. And most of us appreciate
your generosity.
At the same time, we feel that there are better ways
of solving the same problems: ways that are more
scalable, have better support in the language, often
more effecient, and simply a much more common idiom
(which means that you can get support anywhere).
If someone were to come to us with a script suffering
from problems that could be helped by this module
(namely, a way to grab a quick snapshot of global
state, or potentially to reset global variables at a
fair distance), we would instead suggest that they
fix the code to use the tools the language offers
directly for local control, information hiding, and
disposing of variables that are no longer needed.
The fact that your module exhibits exactly those
problems that it tries to fix / support is what has
made many of the exchanges here so painful. As just
one example, you might know that you're not using a
variable anywhere else, so you feel comfortable
leaving it globally accessable; we don't know your
codebase, and since you weren't explicitly marking it
locally controlled (with my or
local), we had to assume that there
might be other users, and therefore any change to it
would be fragile.
Anyway. I wish you luck with this code, and hope
that you don't have to use it too often. :)
| [reply]
[d/l]
[select] |
|
|
|
|
| |
|
Can't believe I'm jumping in here again, but:
One of the reasons I'd be reluctant to release a subroutine of my script as a Perl module is that it would probably be pounced upon and improved beyond recognition and beyond my ability to work with it any longer, and I wouldn't want to lose my first baby.
if this is true, then you are not yet a professional-level programmer, nor ready for a public review cycle. Please learn that you are not your code. It's not "your baby". This sort of pride will keep you from learning what you need to learn to become a better programmer, and perhaps even in some ways, a useful programmer.
Code is just code. A series of steps that you happened upon while trying to solve a problem in order to solve it repeatedly. There are very likely always better steps to do the same thing. It's not personal when someone says "here are better steps": it's just what it is, better steps!
The end product of coding is getting the job done. Not having something
pretty to look at. This is technical work, not art.
I can now see why you react so badly to feedback, if you truly believe this way. And my hope for you is that some day, you'll realize how narrowing and ineffective your view forces you to be.
| [reply] |
|
|
|
|
