153 reputation
6
bio website
location
age
visits member for 1 year, 8 months
seen Jul 21 at 7:53

Dec
8
awarded  Editor
Dec
8
revised Is changing the type of a variable partway through a procedure in a dynamically typed language bad style?
deleted 1 characters in body
Apr
1
comment Is (1/(1/x)) always a perfect round trip?
So many terrible answers here, but this one actually addresses the specific question that was asked. I can't believe the sheer number of people who just said 'no, because of floating point precision' and thought that was good enough, without any proof or examples to show that the rounding errors from the two reciprocations wouldn't always cancel out (or as you would put it, that some non-fixed points of double-reciprocation of mantissas exist :P). A big +1, although this feels a little terse and intimidating at present.
Apr
1
comment Is (1/(1/x)) always a perfect round trip?
-1, because you've just explained how the limited precision of floating points can lead to rounding errors without showing, or even trying to show, that it can cause the specific problem the question asked about. Without either a little testing or a little mathematics, it's pretty non-obvious to me whether the rounding error on the second division will cancel out the rounding error on the first division sometimes, always, or never.
Apr
1
awarded  Critic
Feb
20
accepted Is changing the type of a variable partway through a procedure in a dynamically typed language bad style?
Feb
18
awarded  Scholar
Feb
18
comment Is changing the type of a variable partway through a procedure in a dynamically typed language bad style?
This seems like a reasonable objection, and I think I'll try to phase this kind of style out of my code. Followup: how would you name different variables that conceptually refer to the same thing, but with different types? Hungarian notation is kind of ugly, and trailing types (like having response_addurlinfo, response_str, response_dict) are uglier still. What do you do?
Feb
17
asked Is changing the type of a variable partway through a procedure in a dynamically typed language bad style?
Feb
9
comment Is declaring fields on classes actually harmful in PHP?
@Deco Not comparable because abandoning an entire language is a much larger change than just commenting out declarations in PHP. Jarrod's answer is useful because - while I query or challenge parts of it - it points out some actual downsides, none of which I knew about when I posted the question. A better comparison - were it not for the tool-related downsides - would be something like using "use strict" in Javascript. Yes, you can always say it's pointless because you'd rather just not make the errors it protects you from by being a flawless human, but I'll take the help if it's free.
Feb
8
awarded  Commentator
Feb
8
comment Is declaring fields on classes actually harmful in PHP?
You may be right. I spent a couple of hours tracking down a bug today that turned out to be caused entirely by such a typo, and was frustrated afterwards by the sudden realization that if I'd only not used field declarations, I would've got a notice and known immediately where my error was (which I'd always thought would happen in these circumstances anyway; I didn't realize declarations initialized fields to null). The immediate accessibility of that experience is probably skewing my judgement of how likely it is to recur, or how worthwhile it is to defend against.
Feb
8
comment Is declaring fields on classes actually harmful in PHP?
In response to your proposed solution: this is precisely what I want to avoid - the assignment of defaults even when they are meaningless and the default values should never be used. The problem with these defaults (and with declaration without assignment, which just assigns null) is that if, due to a programming mistake, I don't assign a value to something in the constructor when I ought to, then rather than PHP giving a warning when I try to use that value later - helping me spot my error - everything will seem to work fine even though the class is broken.
Feb
8
comment Is declaring fields on classes actually harmful in PHP?
In response to your 5 downsides: 1 (Performance): Do you have a source for this? 2 (Readability): Not sure I understand; the proposal was for commenting out the declarations, not just removing them, so what readability is lost? Slightly less friendly syntax highlighting and potential difficulty distinguishing from neighboring comments, I guess? 3: This one I don't understand at all; can you clarify? 4 (IDEs): Fair enough - I don't have experience of coding PHP with an IDE and didn't know about Eclipse's type hinting. 5 (doc generators): Fair enough - never used one of these.
Feb
8
awarded  Student
Feb
8
comment Is declaring fields on classes actually harmful in PHP?
@FrancisAvila Fair enough, but if you're using declarations and null is a valid value for the field then you can't even check if the field is uninitialized from the getter by any mechanism that I know of; without the declaration, you could throw an exception if property_exists returns false.
Feb
8
comment Is declaring fields on classes actually harmful in PHP?
@PO'Conbhui Sure, there are an infinite variety of possible programming errors that you won't be protected from by PHP reporting on attempts to read an uninitialized variable. The same is true of any other kind of debugging aid. I don't see how your argument doesn't apply equally to, for example, syntax checking tools in IDEs. The purpose of such tools isn't to protect you from all errors; it's to protect you from a specific subset of possible kinds of errors. But that doesn't mean they're worthless.
Feb
8
comment Is declaring fields on classes actually harmful in PHP?
@EdHeal I don't mean to be obtuse, but "saying something about the contract" === "documenting the contract", right? My exact point was that using commented out declarations preserves that benefit - unless you need the declarations to be parsable by tools, which as MichaelBerkowski points out is a scenario I hadn't considered.
Feb
8
comment Is declaring fields on classes actually harmful in PHP?
@FrancisAvila Sure - unless I don't know what a meaningful value will be until during or after instantiation, which is the case for most fields that aren't class constants. Just assigning a default value (probably of 0, or null, or "") at declaration time provokes exactly the same error-concealing behaviour as declaring without assignment.
Feb
8
comment Is declaring fields on classes actually harmful in PHP?
@CrayonViolent You mean a level at which assigning to an undeclared field triggers a warning? That sounds like an improvement on using the default notice level along with declarations. But is it an improvement on using the default notice level with commented-out declarations? If so, why?