2009/1/17 Nathan Rixham <nrixham@xxxxxxxxx>: >>>>> it's a simple need: if I can type that my variable can only contain an >>>>> int, >>>>> then I know it's always an int without tonnes of checks to check it >>>>> actually >>>>> contains an int / is getting set with an int throughout the rest of the >>>>> app >>>>> (especially when multiple dev's are working on it). >>>> >>>> I would argue that what you have is a want based on your current >>>> implementation strategy, rather than a "need". I've never come across >>>> any situation where static types would make my code more secure. If >>>> your code can't control what you're putting into variables then you >>>> have bigger problems than the 5% of your "needs" PHP doesn't meet. >>> >>> won't make code more secure to the outside world, but it will ensure all >>> developers using my code use it correctly; I can currently control it >>> using >>> PHP however it's v complex to do correctly throughout an application >>> compared to having static types. >> >> Then your functions/methods should be checking their inputs in the >> same way you check the inputs from users. I recall a function I wrote >> a while ago which allowed the first line of each function and method >> did something like this... >> >> check_args(func_get_args(), 'error', 'int', 'string:30', 'int:5-100', >> 'bool'); >> >> First argument is the array of arguments. > > nice, seen similar for validating forms; > >> Second it what the function should do in the case of an incorrect >> argument - in this case to trigger a user error. Other options here >> were 'warning', 'notice', 'email:user@xxxxxxxxxx' and true. Most of >> those should be self-explanatory, and if true is passed then an error >> message is returned. >> >> The rest of the arguments should be one per function argument stating >> what's allowed. The options here were numerous and I can't remember >> them all, but you get the idea. >> >> This single function made validating arguments for any function or >> method a doddle and extremely flexible. Could your static types >> validate the length of a string or ensure an integer it within a >> range? > > yeah to some extent; but also would be more like calling a series of setters > each one validating it's input on set so.. <snip code> > then you're validating at setter level and using the setters in the > construct / sure you follow.. Yes, but that's a different problem. You can't validate method arguments using setters, which is essentially the requirement you're looking to achieve. My point was that validation usually goes beyond type and getting into the habit of writing your own validation for each function/method is a good habit to get into. > incidently, if you can see the benefits of this you'll probably see the how > method overloading would be needed.. should be a no arg construct in there > too by rights; otherwise you can't instantiate without having all vals, > either that or you default all to null which you don't want in all cases. Not really. If variables are missing that's an error. And for optional arguments they'd have default values which would always validate correctly (unless you don't want them to). >>>> Any data coming from the user would need the same amount of validation >>>> regardless of whether you were stuffing it into untyped or typed >>>> variables. IMHO the same goes for any uncontrolled inputs to isolated >>>> code regardless of whether it's expected to be reused or not. >>> >>> from the user yup.. but this is about development and developers. >> >> See my answer above - IMHO there's no difference since when you're >> writing code for other developers to use they are your users and >> should be treated as stupid and/or malicious, just like your website >> users. > > i try to think of them like that but they don't like it; specially the other > seniors (not to mention those on this list) > > <lol> I don't verbalise my opinion of the developers I work with, but I've always been a defensive coder (first real job was in the nuclear monitoring industry) so I naturally don't trust anyone else, developer or user. >>>>>>> b: Object superclass >>>>>>> A base class type which all objects automagically extend, with (if >>>>>>> nothing else) a unique id / hashcode for each object (much like the >>>>>>> Java >>>>>>> Object class). Failing this some form of function to get a unique >>>>>>> reference >>>>>>> string for any variable. Example >>>>>> >>>>>> Why should each class automaticaly extend a base class? For what >>>>>> purpose? >>>>>> For what benefit? I can achieve what I want without this *feature*, so >>>>>> I >>>>>> don't need it. >>>>> >>>>> 2 reasons: >>>>> 1: it would allow all objects to have this uniqueid/hashcode i need >>>> >>>> Really don't see why this is necessary. Please elaborate on why you want >>>> this? >>> >>> said to jochem before, same reasons spl_object_hash was created etc etc / >>> orms, persitance etc >> >> IMHO an ORM should be wrapping scalar values in objects but that's >> probably just me. > > exactly! I agree completely, this is half the point, static types would > allow one to make Classes for each of the scalar/primative types and have > them automatically converted to there db specific value by the orm; Don't need types to do that, you have the is_string, is_integer, etc functions so you can already handle that. > extra: would open up the door for having an magic method __cast on all > objects so you could cast (String)'a string' - where String is the object > wrapper for scalar string :) I think you're basically asking for PHP to change so all basic types are objects. I've often thought this would be a good idea but it potentially raises some BC issues and would likely be a substantial and unnecessary performance hit, especially for purely procedural code. >>>>>> Absolute rubbish! You have obviously been used to a different language >>>>>> and >>>>>> have recently moved to PHP, but cannot get used to the fact that it >>>>>> *IS* >>>>>> a >>>>>> different language, therefore it has different syntax and achieves >>>>>> similar >>>>>> things in different ways. If your feeble brain can't handle the >>>>>> differences >>>>>> then I suggest you stick with your previous language and LEAVE PHP >>>>>> ALONE! >>>>> >>>>> actually I've been a senior php dev for 5 years and muddled along >>>>> trying >>>>> to >>>>> help people out on this list for a long time too - it is my primary >>>>> language, PHP always changes and the beauty of the language is that it >>>>> tries >>>>> to allow people to program the way they want, hence it being both >>>>> procedural >>>>> and object orientated, obviously there's a need for this otherwise Type >>>>> Hinting would never have been introduced. >>>> >>>> Type hinting is the happy medium between untyped and strongly typed >>>> variables. >>> >>> yup-ish, could do with that type hinting on vars, properties and return >>> types too (infact if you had it on vars and properties you could forget >>> return types theoretically, wouldn't be quite as contracted but the >>> functional need would be covered).. >> >> Something just occurred to me... what would you want the engine to do >> if a type was not correct at runtime? Throw an exception? Raise a >> fatal error? Or just a notice? Personally I prefer to be in full >> control of what occurs when something unexpected happens. > > same as it currently is for Type Hints on methods, catchable fatal error. > > and you would be in control, catch it. Ahh, but you can't catch those inline so you have to build a generic handler. Let's take the example of a form handler. I have a script that grabs the data posted to the form which calls a method on a class to act on that data. With typed arguments you're forcing the validation to occur outside the method which is where it really ought to be done. This means it will likely need to be duplicated everywhere you need to call that method. Chances are you'll end up writing a non-typed method to handle that, so why not just do the validation in the actual method that's being called all over the place?!! You can ignore the need to validate on the basis that the typed arguments will catch any problems, but then you need to craft your error handler generically and create a very poor user experience. IMHO an exception would be a better choice, at least then I can deal with it in the correct place and maintain the flow of the script. However, I remember reading a while back that having the engine throw an exception into user space is less than simple, but I can't recall the details. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
