• (cs) in reply to Anaerin
    Anaerin:
    I deal with ASP a lot. Essentially all parameters passed in are "StringList"s. The default return value of a StringList is all elements concatenated with commas.

    So, for the URL: thing.asp?test=1&test=2

    Request.QueryString("Test")="1,2"

    However, you can also do:

    Request.QueryString("Test").Count=2
    Request.QueryString("Test").Value(0)="1"
    Request.QueryString("Test").Value(1)="2"

    (Which can be shortened down to Request.QueryString("Test")(0) as "Value" is the default parameter).

    So there's no problems with commas, if you use the objects the way they're meant to be used.


    That looks like VB to me. I can find nothing like a 'default return' in the documentation (there can be no such thing). If Request.QueryString("x") is a list of strings, then it's not a string. It may have an implicit cast to string (bad. Implicit casts should never lose information).

    In fact, the QueryString.Item property is the same as the index or whatever, so QueryString["a"] is the same as QueryString.Item["a"]. Item returns a string. Always. If you want the list of strings, use QueryString.GetValues("a"), which returns a string array.

    If VB has other atrocities which let this work in strange and wonderful ways, I really don't want to know. I don't know of any language that does things based on the "expected return type" - type inference almost always goes one way. That's why languages don't let you overload functions differing only in return type. Otherwise, you get braindead results like (int)(float)f(), which may or may not be different from (int)f().
  • (cs) in reply to JL
    Anonymous:
    ... For instance, if you are displaying many rows from a database search in an HTML table, you'd probably want to split the search result across multiple webpages.  .....  If you don't want to store the state on the server, a hidden form field with comma-separated ids works pretty well.

    Of course, that's a lot of "if"s, many of which don't apply here, but the overall design is not unreasonable.  Perhaps the author copied it from another context where it did make sense?


    If you're reloading the page anyway, the server can set the 'checked' property of the checkboxes fine, all by itself.

    Maybe there are sensible reasons, but only if the javascript parses the value later on the same page.

    And the rule about JavaScript? The page should work just fine without it. If it needs javascript, it's badly designed, obviously by someone who knows nothing about http.
  • (cs) in reply to ammoQ
    ammoQ:
    Anonymous:

    Simple, have $_REQUEST, $_POST and $_GET that work the normal way and have $_REQUEST_ARRAYS, [etc] that return all request values as arrays (whether multi-valued or not). Or have a function that looks into the GET or POST data and works an array if you'd rather do it on the fly than take the processing hit up-front (it's possible to do this yourself but it should be a language feature).

    Yes, that would be the way to go, but it's not compatible with existing programs (register_globals anyone?). And I guess it's against their philosophy. I think they rather keep the program simple and taint the HTML code instead.


    It *is* compatible with existing programs. Really. Existing programs can use blah[] if they really want to. Sensible programs can use _GET_ARRAY. Servers can be configured to allow the old behaviour.

    And if PHP was half decent, it could return the empty array for anything that isn't defined, which is the only sensible abstraction.

    But having had to use PHP, it's broken anyway. I don't know if it reparses pages or caches them, but it has shortcomings that makes ASP.NET leaps and bounds better, even though ASP.NET isn't perfect (it's like programming in VB or JavaScript or CF - people who use it tend to have no idea what's going on).
  • (cs) in reply to Me
    Anonymous:
    ....  I read the docs and realised I should just do:
    var Date = new Date(2000,1,10);
    


    Or you could have just set the day before the month.


    Wrong! Then, when it *is* february, and you set the date to march 29, first it sets it to feb 29 -> mar 1 (on a normal year) and then to march 1 again.

    This is why I hate badly designed date classes.

    Anonymous:
    One day, someone will implement a date object that makes sence.

    Well, ok, maybe not, but the hope keeps me going.

    Java's Date is designed decently, though it should be renamed Time (distinct concept from TimeOfDay). They moved all Calendar functions to Calendar, and there are different calendars, not all of which have months (I think?).

    What someone really needs to do is design something that handles TAI, UTC, and timezone-settings correctly. Calling anything "UTC" on a computer that isn't actively recieving leap-second info is wrong - you get a one-second error if you miss a leapsecond. The better way would be to store the difference to TAI in the timestamp as well (this also lets you deal with times a few years into the future)

    Most unfortunately, the POSIX spec says that time() and gettimeofday() effectively replay leap second as the next second (it returns day*86400+seconds, so day 0 second 86400 and day 1 second 0 are equal). NTP replays leapseconds as the previous second. And other really bad designs.

    I call for all timestamps to be TAI.

    Anonymous:
    How do you pronounce "TTWTASO"?  It's a great design pattern in need of a better acronym.  I can't wait to start my next project and walk up to the current developers and say: Hi guys I was looking over the code and I got to say this was an excellent use of the TTWTASO design pattern.


    I propose "t-tw_t-assh_l_", with a stutter. Blanked because I don't know if it'll be deleted if I don't (or even if I do).
  • (cs) in reply to TeeSee

    TeeSee:
    I don't know of any language that does things based on the "expected return type" - type inference almost always goes one way. That's why languages don't let you overload functions differing only in return type. Otherwise, you get braindead results like (int)(float)f(), which may or may not be different from (int)f().

    Perl allows a function to tell whether it was called in list, scalar or void context, and change its behaviour accordingly: http://search.cpan.org/dist/perl/pod/perlfunc.pod#wantarray.  Haskell allows overloading on the return type, for example http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v%3AfromInteger.  There are probably other languages that have something similar - IIRC someone here mentioned a while back that Ada could do it.

    TeeSee:
    Wrong! Then, when it *is* february, and you set the date to march 29, first it sets it to feb 29 -> mar 1 (on a normal year) and then to march 1 again.

    This is why I hate badly designed date classes.

    Anonymous:
    One day, someone will implement a date object that makes sence.

    Well, ok, maybe not, but the hope keeps me going.

    Java's Date is designed decently, though it should be renamed Time (distinct concept from TimeOfDay).

    Do you mean this one: http://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html?  Because it behaves the same as JavaScript's Date in this case, and IIRC the JavaScript one is actually just a straightforward translation of the Java one.

  • (cs) in reply to iwpg
    Java's Date is designed decently, though it should be renamed Time (distinct concept from TimeOfDay).

    Do you mean this one: http://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html?  Because it behaves the same as JavaScript's Date in this case, and IIRC the JavaScript one is actually just a straightforward translation of the Java one.



    They realised it was a WTF and deprecated anything to do with calendars in Date (except toString(), which is an allowable exception, though perhaps it should display UTC). A Date is an instant in time (to some precision), and functions to convert it to calendar dates and back are in Calendar. And if you use Calendar's set() methods, you won't get this WTF. GregorianCalendar improves on it a bit more - one month after Jan 31 is Feb 28/29.

    .NET has yet to make the distinction.

Leave a comment on “A New Type of Formation”

Log In or post as a guest

Replying to comment #:

« Return to Article