|
|
Posted by Steve on 04/20/07 16:56
"Moot" <usenet@mootsoft.com> wrote in message
news:1177085607.182037.77100@d57g2000hsg.googlegroups.com...
| On Apr 20, 8:39 am, Jim <j...@yahoo.com> wrote:
| > 1. Use getters and setters (hate the idea of them though)
| > 2. Use __get and __set which I prefer the idea of from a user
| > interface point of view though I understand they take no notice of
| > member visibility.
|
| Really? Because I've always found __get and __set to be completely
| *UN*intuitive from a user interface point of view.
big question mark here.
| To me, the whole concept and reason for making a class is so that you
| can encapsulate logic and present the user (remember, the user of your
| class isn't the end user, it's you or another programmer) with a clear
| set of "here's what you can do with this object type". Using the
| magic get/set functions means that unless you have intimate knowledge
| of the internal working of the class, you would have *no clue* as to
| what is capable with an object of that class.
reason for the big question mark? because there is nothing magic going on
here. haven't you all programmed in non-scripted languages? here's how they
implement what the op wants...let's say vb.net:
private static myBar as string
public static property bar() as string
get
return myBar
end get
set(byval value as string)
' add some validation
' maybe throw some errors
' else, if all is well
myBar = value
end set
)
same with c#, same with c++, etc., etc..
this would be:
myClass.bar = 'foo'
debug.writeline(myClass.bar)
notice his suggestions encapsulates/protect his variable. all __set/__get
does is pawn off the public call to private getters/setters...emulating the
code above. as for *NO CLUE*...i couldn't disagree more. with both his
scenario and yours, the caller must know that a setter/getter exists.
however, his doesn't limit nomanclature...as ALL of your object's interfaces
must begin with either 'get' or 'set'...in his, you just name a variable
whatever you want. if you rhs it and he wants it to be read-only, he just
adds a switch in __get and throws an error.
so what gives?
| Here's an example:
| Say you and I are working on a web app. You've created a class to
| wrap around a contact in a user's addressbook. I need to get a list
| of phone numbers to call for some salespeople, so I say, "hey, I'll
| use this handy Contact class my buddy made". I create an object, type
| $contact-> and...??? My IDE's autocomplete pops up with a few
| functions (save, update, etc...), but how do I get the phone number?
| Is it:
| $contact->phone;
| $contact->phonenumber;
| $contact->phone_num;
| $contact->...
| You get the point.
your point is that you want to tailor/limit good coding practices to be
inline with whatever ide of the week is being used. here's my point...the
public vars will still show up as interfaces in an ide's autocomplete. if
you try to write a read-only or read a write-only, guess what...you get an
error. if php wants to help your ide's autocomplete, then maybe they sould
work something out...as has been done with php documentor. then you'd be
able to see the scope, parameters, type, access, etc.. just like in
non-scripted ide's who autocomplete based on the op's code for this
suggested practice.
| Whereas with actual defined get/set functions, it would be very
| intuitive. I'd see getPhoneNum() in the autocomplete and instantly
| know that's what I need to call.
christ...should we now have ide wars to go along with the browser wars? to
which do we yeild our good coding standards/best practices. oh yes, to
sacrifice.
| Yes, it is a lot of extra work to make individual get/set functions,
| and most of them are going to be near identical copy/paste jobs, but
| 12 months down the road when you have long since forgotten how
| *exactly* your class works, which will be easier? Digging into the
| class code to figure out which variable names you're supposed to use,
| or letting your IDE's autocomplete pop up and immediately knowing what
| get function to call. Take the extra time up front and you'll save
| headaches down the line.
i don't know that you've done oop in a non-scripted language. none of your
arguments would make valid sense if you had.
Navigation:
[Reply to this message]
|