Hi guys,
I have an object which represents an "item" in a CMS "component" where
an "item" in the most basic form just a field, and a "component" is
effectively a table.
"item" objects can be created and then added to "component" objects to
build up the component definition.
My dilemma comes in deciding how to read/write data to the "item"
object.
I figure I can either:
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.
3. Pass all the required parameters to one function and do all the
validation there - inflexible, unintuitive and more work in the long
run in my opinion.
I'm leaning towards the __get and __set route so I could do:
$item = new Item('user');
// could throw exceptions in the functions that do validation
$item->required = true;
$item->label = 'User';
$item->description = 'A description of the item';
// all validation on the item is done so just add it
$component->add_item($item);
Does this make sense? I'm interested in hearing what other methods
people would choose and why.
Thanks for any input.
Jimmy.
41  2777 
| 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.
plus, the only get called when the caller makes reference to an interface
that does NOT exist on your object. you cannot for instance, expect to run
code that handles someone setting $obj->foo (which let's say is
valid)...__set will only be called when someone tries $obj->Foo or
$obj->fooo or any other misspelling. afaicr.
| I'm leaning towards the __get and __set route so I could do:
|
| $item = new Item('user');
|
| // could throw exceptions in the functions that do validation
| $item->required = true;
| $item->label = 'User';
| $item->description = 'A description of the item';
not using __set or __get. these vars would simply, and quite happily take
the value of whatever the rhs threw them. perhaps, with enough
encouragement, future versions of php will have built in get/set events for
lhs assignments instead of just having interface access errors begin by
triggering __get/set.
| // all validation on the item is done so just add it
| $component->add_item($item);
add_item could/would be the best place to add validation for $item, imo.
however, you still can't protect $item from someone changing it's values
after add_item has had it's way with it.
| Does this make sense? I'm interested in hearing what other methods
| people would choose and why.
makes sense. i don't worry about anything but data typing in php < 5. after
data-typing errors are covered, i validate and throw errors immediately
before critical operations - saving data, etc.. in 5+, you can type your
variables, so that's less of a concern. however, i still don't do much
validation until it becomes critical.
hth...just mo.
Hi Steve,
| 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.
plus, the only get called when the caller makes reference to an interface
that does NOT exist on your object. you cannot for instance, expect to run
code that handles someone setting $obj->foo (which let's say is
valid)...__set will only be called when someone tries $obj->Foo or
$obj->fooo or any other misspelling. afaicr.
I would have something like a switch statement that made sure the
variables the user is trying to set are valid and runs the appropriate
private function to validate. For example, I might define
"description" as a property which will then exists in the switch list
in the __set function which will then in turn call set_description
which would carry out any validation and store the value in something
like _description. They only thing I really achieve by doing this is
avoiding the user having to call set and get functions, I think it's
worth it though.
add_item could/would be the best place to add validation for $item, imo.
however, you still can't protect $item from someone changing it's values
after add_item has had it's way with it.
I have to disagree with that. It feels most confortable with me to do
validation in the Item object, since in my mind the logic and
behaviour of that object should be contained within itself rather than
creating a dependency on the component object. I'm open to persuation
though.
Thanks,
Jimmy.
| I would have something like a switch statement that made sure the
| variables the user is trying to set are valid and runs the appropriate
| private function to validate.
i understand that. what i'm saying (right from the php docs), is that __set
is ONLY executed in your class by php when an interface that does NOT EXIST
as part of your class is accessed. same thing with __get.
| For example, I might define
| "description" as a property which will then exists in the switch list
| in the __set function which will then in turn call set_description
| which would carry out any validation and store the value in something
| like _description. They only thing I really achieve by doing this is
| avoiding the user having to call set and get functions, I think it's
| worth it though.
yes, and it is the *correct* approach since you should be able to scope the
interfaces as well. HOWEVER PHP DOES NOT SUPPORT THIS. sorry, was i speaking
loudly? :) in the future, perhaps they will. there are many requests out
there now for such support.
| add_item could/would be the best place to add validation for $item, imo.
| however, you still can't protect $item from someone changing it's values
| after add_item has had it's way with it.
|
| I have to disagree with that. It feels most confortable with me to do
| validation in the Item object, since in my mind the logic and
| behaviour of that object should be contained within itself rather than
| creating a dependency on the component object. I'm open to persuation
| though.
given the way you showed $item, i stated my opinion. if you put
getters/setters on $item, i'd not have suggested otherwise and we'd have no
dispute. as it is currently in php (esp. earlier versions), you cannot
guarantee the value of ANY interface variable that is public in scope.
therefore, i usually only fuss about validation before i'm going to do
something critical with what the object represents.
make sense?
Jim wrote:
Hi guys,
I have an object which represents an "item" in a CMS "component" where
an "item" in the most basic form just a field, and a "component" is
effectively a table.
"item" objects can be created and then added to "component" objects to
build up the component definition.
My dilemma comes in deciding how to read/write data to the "item"
object.
I figure I can either:
1. Use getters and setters (hate the idea of them though)
But it's the right way to go. Among other things, it makes the code
much easier to maintain in the future.
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.
You can do it - but now you have to validate the parameter - is it an
actual value? And it will be harder to maintain in the future - more
code to worry about when you add/delete values. Validation also becomes
much more complicated.
3. Pass all the required parameters to one function and do all the
validation there - inflexible, unintuitive and more work in the long
run in my opinion.
About the same as using __set, isn't it?
I'm leaning towards the __get and __set route so I could do:
$item = new Item('user');
// could throw exceptions in the functions that do validation
$item->required = true;
$item->label = 'User';
$item->description = 'A description of the item';
// all validation on the item is done so just add it
$component->add_item($item);
Does this make sense? I'm interested in hearing what other methods
people would choose and why.
Thanks for any input.
Jimmy.
From the point of clarity, ability to later modify the code, etc., I
much prefer getters and setters. Sure it means you may have a lot of
functions - but there won't be the independence on other code you have
with other ways. It will probably be faster, also.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Apr 20, 8:39 am, Jim <j...@yahoo.comwrote:
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.
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.
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.
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.
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.
--
Moot
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:yu******************************@comcast.com. ..
| Jim wrote:
| Hi guys,
| >
| I have an object which represents an "item" in a CMS "component" where
| an "item" in the most basic form just a field, and a "component" is
| effectively a table.
| >
| "item" objects can be created and then added to "component" objects to
| build up the component definition.
| >
| My dilemma comes in deciding how to read/write data to the "item"
| object.
| >
| I figure I can either:
| >
| 1. Use getters and setters (hate the idea of them though)
|
| But it's the right way to go. Among other things, it makes the code
| much easier to maintain in the future.
actually, no, it doesn't. he wants to use a switch in __set/__get and call
the appropriate PRIVATE getter/setter. PLUS, in doing so, he'd have
simplified the object's interface. there is NO difference affecting the
maintainability or scaling of the object in the future.
only problem is, __set/__get only works when a *non-existent*
method/property is getted/setted.
| 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.
|
| You can do it - but now you have to validate the parameter - is it an
| actual value?
the parameter is always $value. all he'd have to do in his scenario is take
the __set value as a variant/non-typed variable. his private setter could
strongly type the param which would throw errors automatically in php if the
param type didn't match.
| And it will be harder to maintain in the future - more
| code to worry about when you add/delete values. Validation also becomes
| much more complicated.
i'm not sure you follow what he's saying, otherwise you'd see that your
'preferred' getting/setting is identical (though less effective) to how he's
wanting to implement __set/__get - which is only a middle-man between the
scopes of public and private. validation still happens in the same
place...getters/setters (your preference noted)...what changes is that HIS
getters/setters would have PRIVATE scope and would run automatically and
with LESS code for the developer and the end consumer. ex.,
his implementation:
$foo->bar = 'hello world';
echo $foo->bar;
yours:
$foo->setBar('hello world');
echo $foo->getBar();
to me the consumer, i *prefer* the former. now i think you can imagine what
the code for the class would be in both scenarios. i can spell that out for
you too if needed. BOTH would have setBar() and getBar() however...which is
why i can't see how you derive your 'preference' based on your point of
contention for said opinion(s).
| 3. Pass all the required parameters to one function and do all the
| validation there - inflexible, unintuitive and more work in the long
| run in my opinion.
again, the same goes here. and, i'll not flog a dead horse any more than i
have to.
| About the same as using __set, isn't it?
obviously not. consumer get ONE interface to deal with in his scenario.
| From the point of clarity, ability to later modify the code, etc., I
| much prefer getters and setters. Sure it means you may have a lot of
| functions - but there won't be the independence on other code you have
| with other ways. It will probably be faster, also.
again, he's not doing away with them. he makes them private and the built-in
__set/__get takes over publically as the middle-man for the public
interface. and, as __set/__get ARE built-in, nothing you could script will
execute any faster. as for 'independence' (i think you mean loose coupling),
__set/__get of the class passes params to the appropriate private
getters/setters. since they are part of the same object, there is NOTHING to
decouple.
i hate to take the arrows from your quiver, but i just don't think you
understand the post.
finally, i must say again. __get/__set only execute from php when a
non-existent interface is accessed. so, no worries jerry, we're still suck
with public getters/setters...for now.
"Moot" <us****@mootsoft.comwrote in message
news:11*********************@d57g2000hsg.googlegro ups.com...
| On Apr 20, 8:39 am, Jim <j...@yahoo.comwrote:
| 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.
Steve wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:yu******************************@comcast.com. ..
| Jim wrote:
| Hi guys,
| >
| I have an object which represents an "item" in a CMS "component" where
| an "item" in the most basic form just a field, and a "component" is
| effectively a table.
| >
| "item" objects can be created and then added to "component" objects to
| build up the component definition.
| >
| My dilemma comes in deciding how to read/write data to the "item"
| object.
| >
| I figure I can either:
| >
| 1. Use getters and setters (hate the idea of them though)
|
| But it's the right way to go. Among other things, it makes the code
| much easier to maintain in the future.
actually, no, it doesn't. he wants to use a switch in __set/__get and call
the appropriate PRIVATE getter/setter. PLUS, in doing so, he'd have
simplified the object's interface. there is NO difference affecting the
maintainability or scaling of the object in the future.
only problem is, __set/__get only works when a *non-existent*
method/property is getted/setted.
| 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.
|
| You can do it - but now you have to validate the parameter - is it an
| actual value?
the parameter is always $value. all he'd have to do in his scenario is take
the __set value as a variant/non-typed variable. his private setter could
strongly type the param which would throw errors automatically in php if the
param type didn't match.
| And it will be harder to maintain in the future - more
| code to worry about when you add/delete values. Validation also becomes
| much more complicated.
i'm not sure you follow what he's saying, otherwise you'd see that your
'preferred' getting/setting is identical (though less effective) to how he's
wanting to implement __set/__get - which is only a middle-man between the
scopes of public and private. validation still happens in the same
place...getters/setters (your preference noted)...what changes is that HIS
getters/setters would have PRIVATE scope and would run automatically and
with LESS code for the developer and the end consumer. ex.,
his implementation:
$foo->bar = 'hello world';
echo $foo->bar;
yours:
$foo->setBar('hello world');
echo $foo->getBar();
to me the consumer, i *prefer* the former. now i think you can imagine what
the code for the class would be in both scenarios. i can spell that out for
you too if needed. BOTH would have setBar() and getBar() however...which is
why i can't see how you derive your 'preference' based on your point of
contention for said opinion(s).
| 3. Pass all the required parameters to one function and do all the
| validation there - inflexible, unintuitive and more work in the long
| run in my opinion.
again, the same goes here. and, i'll not flog a dead horse any more than i
have to.
| About the same as using __set, isn't it?
obviously not. consumer get ONE interface to deal with in his scenario.
| From the point of clarity, ability to later modify the code, etc., I
| much prefer getters and setters. Sure it means you may have a lot of
| functions - but there won't be the independence on other code you have
| with other ways. It will probably be faster, also.
again, he's not doing away with them. he makes them private and the built-in
__set/__get takes over publically as the middle-man for the public
interface. and, as __set/__get ARE built-in, nothing you could script will
execute any faster. as for 'independence' (i think you mean loose coupling),
__set/__get of the class passes params to the appropriate private
getters/setters. since they are part of the same object, there is NOTHING to
decouple.
i hate to take the arrows from your quiver, but i just don't think you
understand the post.
finally, i must say again. __get/__set only execute from php when a
non-existent interface is accessed. so, no worries jerry, we're still suck
with public getters/setters...for now.
Oh, I understand exactly what he's saying. But I don't have my head up
my ass like you do.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
| Oh, I understand exactly what he's saying. But I don't have my head up
| my ass like you do.
seems all evidence is to the contrary. and your strong, emphatic opinion(s)
about the matter just makes your backpeddling even more arduous.
:)
Message-ID: <Eu*************@newsfe02.lgafrom Steve contained the
following:
>| Oh, I understand exactly what he's saying. But I don't have my head up
| my ass like you do.
seems all evidence is to the contrary. and your strong, emphatic opinion(s)
about the matter just makes your backpeddling even more arduous.
:)
I thought you two had *PLONK*ed each other?
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/
"Geoff Berrow" <bl******@ckdog.co.ukwrote in message
news:nv********************************@4ax.com...
| Message-ID: <Eu*************@newsfe02.lgafrom Steve contained the
| following:
|
| >| Oh, I understand exactly what he's saying. But I don't have my head up
| >| my ass like you do.
| >
| >seems all evidence is to the contrary. and your strong, emphatic
opinion(s)
| >about the matter just makes your backpeddling even more arduous.
| >
| >:)
| >
|
| I thought you two had *PLONK*ed each other?
yes...i was laughing at that too. however i have a highly customized version
of oe and have programmed in selective plonking. when i *PLONK*, it's on a
per thread basis. when i think someone is a total fuckwit, PLONK!!! makes
them invisible to me. while my good friend jerry may get there some day, he
still has some good advice from what i've seen. i have other features like
aliasing a poster's nym. i may give jerry one...how does 'stucco - can't
filter language from sound advice' work?
On Apr 20, 12:56 pm, "Steve" <no....@example.comwrote:
"Moot" <use...@mootsoft.comwrote in message
| 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:
The word "magic" was not me being cute, it's the actual terminology
used in the PHP manual: http://us2.php.net/manual/en/language.oop5.magic.php
Quote: "The function names __construct, __destruct (see Constructors
and Destructors), __call, __get, __set, __isset, __unset (see
Overloading), __sleep, __wakeup, __toString, __set_state, __clone and
__autoload are magical in PHP classes."
>
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
)
Yes, I've done plenty of .NET programming, but do you see what you did
there? You created a Getter/Setter specifically for the variable
MyBar, you didn't rely on a "magic" (again, the *actual term*) method
to interpret which private variable you wanted. You specifically
defined that to get myBar, you need to call 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.
If you're going to have private get/set functions, why not just make
them public? Why add the extra layer of redirection?
>
| 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.
But since we're debating this, I can assume that we all acknowledge
that getter/setter functions in any implementation are far superior to
allowing the user to access the variable directly, so there should be
no public variables visible to the user. Internal object variables
should always be wrapped in some kind of get/set function.
>
| 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.
Okay, I see that my mentioning an IDE as an analogy went right over
your head. It was a liberty I took to make the example easier, but I
see that I need to be more specific for you. Say you write a class
that I later want to use. We'll look at it as if you've done it 3
different ways:
A - you use the __get/__set methods to allow the user to access
private variables
B - you use the __get/__set methods to allow the user to access
private variables by going through a private getter/setter function
C - you make seperate getter/setter functions for each private
variable
Now, to know how to use that class (and, so you don't get snippy, I'll
code in Notepad for the sake of this argument), I have to:
A - go to the __get function and examine the code (including any if/
else or switch conditional logic there may be) to determine what X to
call so that it will return me Y
B - same as A, only now I find that X points me to Z, which returns me
Y
C - find the appropriate getX function
Maybe in a small class this concept is trivial, but any decently sized
class using __get is eventually going to end up being full of
conditional switching. Also, if I've been a good little programmer
and set up my code for auto-documentation generation, then the
generated interface for the object will show all getter/setter
functions, but will completely ignore any conditional switching
located inside of a __get function.
| 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.
Here's my main point: __get allows you to make your class dynamic in
that you can call $obj->anything and let the class figure out what
that "anything" means. That's all fine and dandy for the person
writing the class, and often makes their life easier. But you don't
code OOP for yourself, you code it for the person using the objects,
whether that be you or a team of a dozen other programmers. When you
make your class able to accept "anything", then how does the user know
that $obj->foo is allowed, while $obj->bar is undefined? They don't,
unless they open up your code to figure out what the heck you were
thinking when you wrote it.
Bottom line: the __get/__set functions enable developers to hide the
interface to the object INSIDE of the object. Since the interface is
how you are expected to interact with an object, it needs to be fully
exposed and visible to the outside user. The only way to do this is
with publicly visible getter/setter functions
- Moot
"Moot" <us****@mootsoft.comwrote in message
news:11*********************@y80g2000hsf.googlegro ups.com...
| On Apr 20, 12:56 pm, "Steve" <no....@example.comwrote:
| "Moot" <use...@mootsoft.comwrote in message
| | 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:
|
| The word "magic" was not me being cute, it's the actual terminology
| used in the PHP manual:
| http://us2.php.net/manual/en/language.oop5.magic.php
| Quote: "The function names __construct, __destruct (see Constructors
| and Destructors), __call, __get, __set, __isset, __unset (see
| Overloading), __sleep, __wakeup, __toString, __set_state, __clone and
| __autoload are magical in PHP classes."
let's just say they are *reserved* words as all other language constructs
have. however, *those* are all built-in to php and are a construct by which
all must abide. using getters/setters truly IS magic. as i said earlier,
setting a property in your example would mean that all properties have
associated getProperty/setProperty (for transparency). the preamble
(get/set) is a construct of your own making and you require it as a
construct yourself.
using __set/__get, were it to work the way the op thinks is does, let's you
name a property *ANYTHING* and your private getters/setters can be named
*ANYTHING*...further, it completely decouples special knowledge about your
home-brewed construct of getProperty/setProperty (no matter how commonly
used by others).
i'm not trying to argue with you here. i'm trying to be as technically
accurate as possible.
| >
| 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
| )
| >
|
| Yes, I've done plenty of .NET programming, but do you see what you did
| there? You created a Getter/Setter specifically for the variable
| MyBar, you didn't rely on a "magic" (again, the *actual term*) method
| to interpret which private variable you wanted. You specifically
| defined that to get myBar, you need to call 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.
|
| If you're going to have private get/set functions, why not just make
| them public? Why add the extra layer of redirection?
well, you may want to have mixed scopes on properties - private set/ public
get. you may want to have a setter ONLY IN YOUR CLASS so that the validation
(which may refer to private members) can be handled uniformly
(self::propertySetter). and since you can't truly overload in php, there's
no way to have a public setter and a private setter at the same time - both
doing different things. that means you're stuck adding more magic
nomanclature for the private setter. the other way though, you can have a
public setter AND a private setter, calling them what you will.
plus, it is a hugely transparent operation for the developer. forget that
they don't have to know your prefixing the property with get/set. there is
less to code. as i showed,
$foo->bar = 'hello world';
echo $foo->bar;
much neater to me. on the back-end, my class is more uniformly defined: one
section defines the interfaces, the next with their private getters/setters,
and then finally ONE place where each getter/setter is utilized and where
the bulk of simple data validation would occur...leaving the getters/setters
to simply focus on the business logic rather than both.
| 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.
|
| But since we're debating this, I can assume that we all acknowledge
| that getter/setter functions in any implementation are far superior to
| allowing the user to access the variable directly, so there should be
| no public variables visible to the user. Internal object variables
| should always be wrapped in some kind of get/set function.
for ANY property to be set, you HAVE TO HAVE a getter and setter. what we're
talking about is having php allow us to detect the event and validate the
rhs value being assigned to the property.
as for 'is it a good idea to let users directly massage properties?'...SURE
IT IS. it just depends on what you're doing with the information and how you
are going to validate it, if at all. using NEVER is a strong word. i have a
ton of singleton's that are all public static variables. the methods on the
object are what are used in most of those classes. gi == go...plus i tell
them if anything is amiss with properties when they are used. that too could
be advantagous as well. think of a setter/getter on an obj in a loop. were
validation going on behind each get/set and the loop happened many times,
THAT could be a huge lag on the cpu. however validation when needed means
the final value of the property would be analyzed only after the
loop...speeding things up much quicker.
| >
| | 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.
| >
|
| Okay, I see that my mentioning an IDE as an analogy went right over
| your head. It was a liberty I took to make the example easier, but I
| see that I need to be more specific for you. Say you write a class
| that I later want to use. We'll look at it as if you've done it 3
| different ways:
| A - you use the __get/__set methods to allow the user to access
| private variables
| B - you use the __get/__set methods to allow the user to access
| private variables by going through a private getter/setter function
| C - you make seperate getter/setter functions for each private
| variable
| Now, to know how to use that class (and, so you don't get snippy, I'll
| code in Notepad for the sake of this argument), I have to:
| A - go to the __get function and examine the code (including any if/
| else or switch conditional logic there may be) to determine what X to
| call so that it will return me Y
| B - same as A, only now I find that X points me to Z, which returns me
| Y
| C - find the appropriate getX function
there is NO conditional stuff going on in __set/__get. it should contain a
switch that calls the appropriate private getter/setter, passing along its
arguments.
now, you're in the EXACT SAME delima as if we used PUBLIC getters/setters.
so, your point here becomes? that you have to look at the switch to see what
the private getter/setter name is? if that's the case, just have the law of
the land be the same...everything in a class the returns a prop value begins
with 'get' and those that set prop values begin with 'set'. but, again
you've made no real point here...that i can see.
| Maybe in a small class this concept is trivial, but any decently sized
| class using __get is eventually going to end up being full of
| conditional switching. Also, if I've been a good little programmer
| and set up my code for auto-documentation generation, then the
| generated interface for the object will show all getter/setter
| functions, but will completely ignore any conditional switching
| located inside of a __get function.
you make a lot of assumptions here, none of which you can back up. the
switch is how it is programmed. if you want to complicate the mechanism
beyond what i've described, then, yes, it could get ugly. however, my idea
of the switch is mearly to act as a stub to which is passes information to
the appropriate 'in/out' box.
are you simplifying here again? you literally mean this time that we are so
sacrifice solid best practices - not for an ide this time - for an
'auto-documentation' generator? my former comments on this frivolity apply
here as well...so i'll leave it at that.
| | 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.
|
| Here's my main point: __get allows you to make your class dynamic in
| that you can call $obj->anything and let the class figure out what
| that "anything" means. That's all fine and dandy for the person
| writing the class, and often makes their life easier. But you don't
| code OOP for yourself, you code it for the person using the objects,
| whether that be you or a team of a dozen other programmers. When you
| make your class able to accept "anything", then how does the user know
| that $obj->foo is allowed, while $obj->bar is undefined? They don't,
| unless they open up your code to figure out what the heck you were
| thinking when you wrote it.
if you make $foo a PUBLIC var then even your ide's autocomplete will pick
that up. if it ties into php documentor, then your comments can have the
autocomplete state scope, type, etc., etc. as i've said before.
what the op wants to do IS define $foo, BUT want's php to let him handle
(with __get/__set) $foo when it is on then lhs or rhs of an operation.
again, i don't see you have a point. do you think if you gave some
psuedo-code here that is would help me get on the same page from which
you're reading?
| Bottom line: the __get/__set functions enable developers to hide the
| interface to the object INSIDE of the object. Since the interface is
| how you are expected to interact with an object, it needs to be fully
| exposed and visible to the outside user. The only way to do this is
| with publicly visible getter/setter functions
no, the interface is PUBLIC. what we're hiding and NOT requiring the user to
know is the NAME of our PRIVATE getters/setters. they simply use the
interface either on the lhs or the rhs...making the object's consumption
easier and more decoupled. so NO, 'the only way to do this is' NOT JUST
'with publicly visible getter/setter functions'.
that's the bottom line, imo.
|| 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
|| )
|| >
||
|| Yes, I've done plenty of .NET programming, but do you see what you did
|| there? You created a Getter/Setter specifically for the variable
|| MyBar, you didn't rely on a "magic" (again, the *actual term*) method
|| to interpret which private variable you wanted. You specifically
|| defined that to get myBar, you need to call bar().
__set is a reserved word as is __get...nothing bad about it.
what i think you fail to understand here is that we are getting the same
result as the above doing this:
<?
class foo
{
public static $bar = '';
public static $fighter = '';
private function __construct()
{
// uh oh...is this magic? lol
}
function __get(...)
{
switch (var name)
{
case 'bar' : return self::getBar();
break;
case 'fighter' : return self::getFighter();
break;
default : throw an error here;
}
}
function __set(...)
{
switch (var name)
{
case 'bar' : self::setBar(__set's value param);
break;
case 'fighter' : self::setFighter(__set's value param);
break;
default : throw an error here;
}
}
private function getBar(){ return self::$bar; }
private function getFighter{ return self::$fighter; }
private function setBar($params)
{
// validate
// if not good, throw an error
// else
self::$bar = $params;
}
private function setFighter($params)
{
// validate
// if not good, throw an error
// else
self::$fighter = $params;
}
}
?>
so, how is this different than vb's get/set other than php give ONE place to
handle it (__get/__set). you'd just prefer the gets/sets would be grouped
together with the property def? guess what, it is php...a scripting
language. we don't get properties. we have scoped variables and functions.
that's all.
at least this functionality would make php seem more like an oop instead of
a hacked simulation...using getSomething or setSomething. i wonder what
other languages would use? in english both get/set are short. however in
most other languages, they both are quite long. :) this technique handles
that too, since you don't have to fuck with anything.
"Steve" <no****@example.comwrote in message
news:L1***************@newsfe03.lga...
Having lurked silently, I'll just surface for a mo and see if I can test the
water without taking too many hits ;)
The way I see this you are suggesting using __set and __get in a fashion
that, to a C++ programer, looks somewhat similar to operator overloading.
Ie:
$Obj->prop = 12;
$t = $Obj->prop;
$Obj->prop * 2;
$t = $Obj->prop * 2;
etc.
Personaly I find this appealing as it is more inclined toward the way I
prefer to use objects in C++ when practical.
Of course this may be due to my preference toward that which I am most
familiar, and my lack of experience with php.
Perhaps it does also have some synactic sugeriness about it, but I do have a
sweet coding tooth. The argument that it does break one of the basic
accepted features of oop by giving the internals public scope does have some
merit. However, personaly I've not ever been tempted to access private
props within an object, nor do I ever remember doing so accidently. And, if
I were to provide such a class to another coder and he/she did so, I would
have to wonder at his/her proficiencey. Having an object actualy water
tight is to assume almost complete oblivion on the part of the user.
It would not be something I imagine a very experienced php programer would
find immediately intuitive, but then that is certainly not myself.
Of course, I could actualy be completely off the track, it is very late in
the eve, ooops, no, it's now actualy quite early in the morning here. But
if I am understanding all of this correctly. I think it has merit
personaly. I prefer an object that behaves more like an inbuilt, than one
that doesn't.
Having said all this, its time for a crash dive.
Regards,
Vince
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46**********************@news.optusnet.com.au ...
|
| "Steve" <no****@example.comwrote in message
| news:L1***************@newsfe03.lga...
| Having lurked silently, I'll just surface for a mo and see if I can test
the
| water without taking too many hits ;)
| The way I see this you are suggesting using __set and __get in a fashion
| that, to a C++ programer, looks somewhat similar to operator overloading.
| Ie:
| $Obj->prop = 12;
| $t = $Obj->prop;
| $Obj->prop * 2;
| $t = $Obj->prop * 2;
| etc.
| Personaly I find this appealing as it is more inclined toward the way I
| prefer to use objects in C++ when practical.
| Of course this may be due to my preference toward that which I am most
| familiar, and my lack of experience with php.
| Perhaps it does also have some synactic sugeriness about it, but I do have
a
| sweet coding tooth. The argument that it does break one of the basic
| accepted features of oop by giving the internals public scope does have
some
| merit. However, personaly I've not ever been tempted to access private
| props within an object, nor do I ever remember doing so accidently. And,
if
| I were to provide such a class to another coder and he/she did so, I would
| have to wonder at his/her proficiencey. Having an object actualy water
| tight is to assume almost complete oblivion on the part of the user.
| It would not be something I imagine a very experienced php programer would
| find immediately intuitive, but then that is certainly not myself.
| Of course, I could actualy be completely off the track, it is very late in
| the eve, ooops, no, it's now actualy quite early in the morning here. But
| if I am understanding all of this correctly. I think it has merit
| personaly. I prefer an object that behaves more like an inbuilt, than one
| that doesn't.
| Having said all this, its time for a crash dive.
what's most funny, vince, is that we are arguing complete theory here. php
does NOT support __set/__get in the way the op thinks it does. i wish it
did, then all of this talk may do some good...for me anyway.
cheers.
"Steve" <no****@example.comwrote in message
news:vq****************@newsfe04.lga...
what's most funny, vince, is that we are arguing complete theory here. php
does NOT support __set/__get in the way the op thinks it does. i wish it
did, then all of this talk may do some good...for me anyway.
cheers.
Perhaps not, but I was building a class a few days ago that was basicaly
like below. The array needs to store about 30 vals so I decided to implement
it similar to below.
class C_Obj
{
private $Obj=array('h'=>10,'i'=>12);
private function getVal($name)
{
return $this->Obj[$name];
}
function &__set($name, $val)
{
$name = $val;
}
function __get($name)
{
return self::getVal($name);
}
}
And it does what I want, as I want it to. Not what some would recomend
perhaps, but I am the one who has to use and maintain it.
Admittedly, I might just get hit by a torpedo tomorrow and my replacement
may not like it much :)
Vince
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46**********************@news.optusnet.com.au ...
function &__set($name, $val)
{
$name = $val;
}
function __get($name)
{
return self::getVal($name);
}
}
It's that 'It's very late here' problem again. The __get() was byref not
the __set(), but considering the weight of the data it's probably mute
anyway.
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46***********************@news.optusnet.com.a u...
The constructor is pleading the fifth as it's so late, please forgive me :)
| class C_Obj
| {
| private $Obj=array('h'=>10,'i'=>12);
|
| private function getVal($name)
| {
| return $this->Obj[$name];
| }
| function &__set($name, $val)
| {
| $name = $val;
| }
| function __get($name)
| {
| return self::getVal($name);
| }
| }
yes, but here i must agree with the others. the reason why this works is
because you don't have the object's interface exposed. therefore, php
executes __set/__get. so in this case, the other posters are correct.
what the op is wanting to do with __set/__get is actually define a public
var and handle its getting/setting with private methods. the op proposed
that __set/__get would be the middle-man. it won't in any current release of
php. i'm hoping in future versions that it will, as this would make it very
similar to other oop enabled scripting languages...those that are more
robust at present.
"Steve" <no****@example.comwrote in message
news:1P*****************@newsfe04.lga...
| class C_Obj
| {
| private $Obj=array('h'=>10,'i'=>12);
|
| private function getVal($name)
| {
| return $this->Obj[$name];
| }
| function &__set($name, $val)
| {
| $name = $val;
| }
| function __get($name)
| {
| return self::getVal($name);
| }
| }
yes, but here i must agree with the others. the reason why this works is
because you don't have the object's interface exposed. therefore, php
executes __set/__get. so in this case, the other posters are correct.
Wellllll, errrr, I just tried what is below, and it works on my machine.
class C_Obj
{
public $Obj=array('h'=>10,'i'=>12);
public function getVal($name)
{
return $this->Obj[$name];
}
function &__set($name, $val)
{
$name = $val;
}
function __get($name)
{
return self::getVal($name);
}
}
$obj = new C_Obj;
$obj->h=5;
echo $obj->h."<br>";
echo $obj->getVal('h');
Of course I'ts now 7.15am and I haven't slept, so I could be delusional : )
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46**********************@news.optusnet.com.au ...
I'm clrealy confused, as this one does too.
class C_Obj
{
public $Obj=array('h'=>10,'i'=>12);
private function getVal($name)
{
return $this->Obj[$name];
}
function __set($name, $val)
{
$name = $val;
}
function __get($name)
{
return self::getVal($name);
}
}
$obj = new C_Obj;
$obj->h=5;
echo $obj->h."<br>";
Vince
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46**********************@news.optusnet.com.au ...
|
| "Steve" <no****@example.comwrote in message
| news:1P*****************@newsfe04.lga...
| | class C_Obj
| | {
| | private $Obj=array('h'=>10,'i'=>12);
| |
| | private function getVal($name)
| | {
| | return $this->Obj[$name];
| | }
| | function &__set($name, $val)
| | {
| | $name = $val;
| | }
| | function __get($name)
| | {
| | return self::getVal($name);
| | }
| | }
| >
| yes, but here i must agree with the others. the reason why this works is
| because you don't have the object's interface exposed. therefore, php
| executes __set/__get. so in this case, the other posters are correct.
| >
| Wellllll, errrr, I just tried what is below, and it works on my machine.
i know it does vince. what i'm saying is that your object exposes NO public
interfaces *formally*...none that an end user could see. when you $obj->h, h
is added to the object. what __set/__get is SUPPOSED to be used for is
detecting helping the class detect this infusion/intrusion and throw an
error.
if you had $h as a public variable and then tried to say $obj->h = 'some
value', you'd never have __set be called by php.
give that a try and see what i mean.
"Steve" <no****@example.comwrote in message
news:Ma*****************@newsfe12.lga...
if you had $h as a public variable and then tried to say $obj->h = 'some
value', you'd never have __set be called by php.
give that a try and see what i mean.
class C_Obj
{
public $h=5;
function __set($name, $val)
{
$name = $val;
}
function __get($name)
{
return self::getVal($name);
}
}
$obj = new C_Obj;
$obj->h=15;
echo $obj->h."<br>";
Either my head is now brocken, or my php engine is.
If I understand you correctly, and it's very likely I'm not, the above
shouldn't work. But it does.
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46**********************@news.optusnet.com.au ...
"Steve" <no****@example.comwrote in message
news:Ma*****************@newsfe12.lga...
At last!!!
Got it.
Sorry.
It's calling the var directly now.
Sorry Steve, I should know when to go to bed ;)
Thank you for clarifying,
Regards,
Vince
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46***********************@news.optusnet.com.a u...
It didn't throw an error or warning, but an echo in the __set() showed it
was not being called when the var is public.
Thank you for your patience,
Vince
"Steve" <no****@example.comwrote in message
news:1P*****************@newsfe04.lga...
yes, but here i must agree with the others. the reason why this works is
because you don't have the object's interface exposed. therefore, php
executes __set/__get. so in this case, the other posters are correct.
what the op is wanting to do with __set/__get is actually define a public
var and handle its getting/setting with private methods. the op proposed
that __set/__get would be the middle-man. it won't in any current release
of
php. i'm hoping in future versions that it will, as this would make it
very
similar to other oop enabled scripting languages...those that are more
robust at present.
Ok, now, at last I think I've got it. _set; __get; etc. are native
functions. They exist transparently at all times without requiring you to
implement them. Member vars with a public interface are in effect set end
errr, getted, gotten begetted, begotten whatever, via these normaly
transparent functions. Once you implement these member functions yourself
you are in effect 'overloading' these normaly 'transparent' equivelants.
Therefore, if you access a public member property, and have these functions
defined yourself, php effectively ignores your definition and uses it's own
transparent equivelants with regard to those member vars with public
interfaces.
So, when you define __set(), and __get(), the engine will only allow you to
use the 'overloaded' functions on private, or protected interfaces (I'm
guessing about protected, I haven't tried them). Therefore, in effect,
__get() and __set() __are__ the interfaces in and of themselves.
An error or warning would be to alert you to the fact that your implemented
__get() and or __set() are not being utalized by the engine, and it uses
it's own native versions.
Now I understand why I just couldn't grasp what was being meant by
'overload' in the context of these functions.
Sorry about the verbosity, but if I have anything incorrect I'd rather it
not be overlooked ;)
Thank you very much for your patience. My grey putty is slow to take on new
shapes sometimes, perhaps more than sometimes. :]
Regards,
Vince
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46**********************@news.optusnet.com.au ...
| "Steve" <no****@example.comwrote in message
| news:Ma*****************@newsfe12.lga...
| if you had $h as a public variable and then tried to say $obj->h = 'some
| value', you'd never have __set be called by php.
| >
| give that a try and see what i mean.
| >
| >
|
| class C_Obj
| {
| public $h=5;
|
| function __set($name, $val)
| {
| $name = $val;
| }
| function __get($name)
| {
| return self::getVal($name);
| }
| }
|
| $obj = new C_Obj;
| $obj->h=15;
| echo $obj->h."<br>";
|
| Either my head is now brocken, or my php engine is.
| If I understand you correctly, and it's very likely I'm not, the above
| shouldn't work. But it does.
try this...notice my modification. it clearly shows that __set is NOT called
when setting $obj->h.
class C_Obj
{
public $h=5;
function __set($name, $val)
{
$this->Obj[$name] = $val;
echo '<pre>__set says: ' . $name . '...' . $val . '</pre>';
}
function __get($name)
{
return self::getVal($name);
}
private function getVal($name)
{
return $this->Obj[$name];
}
}
$obj = new C_Obj;
$obj->h=15;
echo '<pre>does NOT trigger __set : ' . $obj->h . '</pre>';
$obj->yourMomma = 'nice lady. no, i really mean it :)';
| Ok, now, at last I think I've got it. _set; __get; etc. are native
| functions. They exist transparently at all times without requiring you
to
| implement them. Member vars with a public interface are in effect set end
| errr, getted, gotten begetted, begotten whatever, via these normaly
| transparent functions. Once you implement these member functions yourself
| you are in effect 'overloading' these normaly 'transparent' equivelants.
| Therefore, if you access a public member property, and have these
functions
| defined yourself, php effectively ignores your definition and uses it's
own
| transparent equivelants with regard to those member vars with public
| interfaces.
that's certainly one interpretation where the evidence won't contradict the
theory you've arrived upon. however, it is wrong. overloading would mean
somehow that php knows to what function __set/__get applies. this is not the
case. again, the important part is that __set/__get only fire if you try to
access a member on an object that does NOT exist in the class. that again
means that there is no association between php and your defined interfaces -
except to say that php gives you a means to detect when someone is trying to
muck with your object without going through your defined interfaces...via
__set/__get. to which your response should be to thow an error.
does that make the distinction more clear?
| So, when you define __set(), and __get(), the engine will only allow you
to
| use the 'overloaded' functions on private, or protected interfaces (I'm
| guessing about protected, I haven't tried them). Therefore, in effect,
| __get() and __set() __are__ the interfaces in and of themselves.
no. they are a means to let the class know someone is __getting or __setting
a property that does not exist in your object's definition.
| An error or warning would be to alert you to the fact that your
implemented
| __get() and or __set() are not being utalized by the engine, and it uses
| it's own native versions.
no.
| Now I understand why I just couldn't grasp what was being meant by
| 'overload' in the context of these functions.
if that were going on. in php, you can't truly overload. you can extend and
replace a function of the base, but this is technically called 'overriding',
not 'overloading'. :)
as it is here, neither of this is going on.
| Sorry about the verbosity, but if I have anything incorrect I'd rather it
| not be overlooked ;)
no worries.
| Thank you very much for your patience. My grey putty is slow to take on
new
| shapes sometimes, perhaps more than sometimes. :]
i think you appologize too much. :)
we are *all* learners. we'll help eachother along.
cheers.
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46***********************@news.optusnet.com.a u...
Well, I was wrong again apparently.
I can set and get the value of a single private member var as long as the
'name' used in the call is anything _but_ the actualy var name.
The more I play with __get and __set, the weirder things get.
The following code should reproduce the behaviour, it does on my 5.0.3.3
version.
<?
class C_Obj
{
private $h=5;
function __set($name, $val)
{
echo "__set() <br>";
$this->name = $val;
}
function __get($name)
{
echo "__get() <br>";
return $this->name;
}
}
$obj = new C_Obj;
$obj->sdfg=15;
echo $obj->d."<br>";
?>
Clearly I have further misunderstandings, and the more I investigate, the
weirder it gets.
Back to the docs.
"Steve" <no****@example.comwrote in message
news:zG****************@newsfe12.lga...
that's certainly one interpretation where the evidence won't contradict
the
theory you've arrived upon. however, it is wrong. overloading would mean
somehow that php knows to what function __set/__get applies. this is not
the
case. again, the important part is that __set/__get only fire if you try
to
access a member on an object that does NOT exist in the class.
Yep, no doubt about it. That is exactly what I found, and as my __set()
_did_ set the properties value [as I had told it too] when it was called, I
lost all sense of reason :)
It works exactly as you describe.
that again
means that there is no association between php and your defined
interfaces -
except to say that php gives you a means to detect when someone is trying
to
muck with your object without going through your defined interfaces...via
__set/__get. to which your response should be to thow an error.
does that make the distinction more clear?
Yep, no doubt about it.
>
| So, when you define __set(), and __get(), the engine will only allow you
to
| use the 'overloaded' functions on private, or protected interfaces (I'm
| guessing about protected, I haven't tried them). Therefore, in effect,
| __get() and __set() __are__ the interfaces in and of themselves.
no. they are a means to let the class know someone is __getting or
__setting
a property that does not exist in your object's definition.
| An error or warning would be to alert you to the fact that your
implemented
| __get() and or __set() are not being utalized by the engine, and it uses
| it's own native versions.
no.
| Now I understand why I just couldn't grasp what was being meant by
| 'overload' in the context of these functions.
if that were going on. in php, you can't truly overload. you can extend
and
replace a function of the base, but this is technically called
'overriding',
not 'overloading'. :)
Yes!! I realy had lost it!
as it is here, neither of this is going on.
| Sorry about the verbosity, but if I have anything incorrect I'd rather
it
| not be overlooked ;)
no worries.
| Thank you very much for your patience. My grey putty is slow to take on
new
| shapes sometimes, perhaps more than sometimes. :]
i think you appologize too much. :)
we are *all* learners. we'll help eachother along.
cheers.
That is actualy very generous of you, no appology forthcoming :)
"Steve" <no****@example.comwrote in message
news:zG****************@newsfe12.lga...
You are undoubtedly aware that this has to be the most misunderstood
behaviour in all of php. Perhaps in all programing in all languages!! The
number of posts I've read in the last few hours that clearly misunderstand
_set() and __get() is astonishing! And all I've gleened from them was
further misunderstanding. Cant blame them realy. You have been trying to
hammer the point home but the nails have just kept bending. I don't think
I've ever been so confused about anything in my life.
Thank you!!
You have my undying grattitude Steve! :)))
Vince
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46***********************@news.optusnet.com.a u...
I disavow any knowledge of the above, and other posts. My machine must have
been infected with a trojan that was being operated remotely by a person, or
persons of malicious intent.
I have been visiting my, errr, grandmother in another country and only
became aware of the previous posts about, errrr hmmm, a few minutes ago.
My cat sometimes walks across the keyboard while trying to escape the dog,
which is usualy eating my homework at the time, and as incredibley unlikely
as it would seem sometimes manages to generate actual readable text.
All of the above may be difficult to beleive, however, as the universe has
been described as being a figment of it's own imagination it is equaly
probable that these posts were also further figments. Yes, I realize that
there is a more probable explaination, however I plead the fifth,
retrospectively perhaps.
Vince Morgan
Vince Morgan wrote:
"Steve" <no****@example.comwrote in message
news:zG****************@newsfe12.lga...
You are undoubtedly aware that this has to be the most misunderstood
behaviour in all of php. Perhaps in all programing in all languages!! The
number of posts I've read in the last few hours that clearly misunderstand
_set() and __get() is astonishing! And all I've gleened from them was
further misunderstanding. Cant blame them realy. You have been trying to
hammer the point home but the nails have just kept bending. I don't think
I've ever been so confused about anything in my life.
Thank you!!
You have my undying grattitude Steve! :)))
Vince
Vince,
It's probably misunderstood because it's pretty much a violation of OO
principles. OO principles indicate you can set and get values - but
that you have separate setter and getter functions for these.
Now you can emulate this in other OO languages such as Java, C++ and
SmallTalk. But it's pretty much frowned upon. Experienced programmers
in these languages pretty much follow the defacto standard to have
separate getter and setter functions of each value you want to be able
to change/retrieve.
Doing it other ways just gets into too much of a hassle.
Now PHP has tried to implement something which really is against OO
principles (so what's new here?).
I've looked at it - but I really don't find it useful. This style is
not implemented in other languages for very good reason - it really
complicates the code, just as these functions do in PHP.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:PI******************************@comcast.com. ..
| Vince Morgan wrote:
| "Steve" <no****@example.comwrote in message
| news:zG****************@newsfe12.lga...
| You are undoubtedly aware that this has to be the most misunderstood
| behaviour in all of php. Perhaps in all programing in all languages!!
The
| number of posts I've read in the last few hours that clearly
misunderstand
| _set() and __get() is astonishing! And all I've gleened from them was
| further misunderstanding. Cant blame them realy. You have been trying
to
| hammer the point home but the nails have just kept bending. I don't
think
| I've ever been so confused about anything in my life.
| Thank you!!
| You have my undying grattitude Steve! :)))
| Vince
| >
| >
|
| Vince,
|
| It's probably misunderstood because it's pretty much a violation of OO
| principles. OO principles indicate you can set and get values - but
| that you have separate setter and getter functions for these.
i think it's because people was to use it as an oop mechanism so they can
have the getters/setters they're used to having in other languages. i
wouldn't mind having __set/__get be a single entry into calling my own
private getters/setters (which is why i've argued that point)...and i can
think of many factors that would lead the php dev group to just leave it at
that for now. again, the problem is that you'd expect php to guard your
objects and throw errors...instead, they just fire those two events in your
object.
i can even understand that though. one of the features of scripting
languages like php and javascript is that you can throw interfaces on
objects you didn't create. at least php is telling you someone is doing it
so you can handle it.
btw, if __set/__get only worked (as everyone expects) on defined interfaces
then there would still not be any oo violations going on. they would be
gateways from which the programmer would appropriately functionality off to
the right private getters/setters that assist any given interface. (i still
don't see how you're missing that point.)
| Now you can emulate this in other OO languages such as Java, C++ and
| SmallTalk. But it's pretty much frowned upon. Experienced programmers
| in these languages pretty much follow the defacto standard to have
| separate getter and setter functions of each value you want to be able
| to change/retrieve.
and if __set/__get worked only on defined interfaces, 'experienced'
programmers would not be lost on the fact that they still would be making
related getters/setters and would be calling them selectively when
__set/__get were fired.
| Doing it other ways just gets into too much of a hassle.
i don't see the big deal, jerry. there are no more additional or magical
steps in using __set/__get than in programming any other property, any other
language.
| Now PHP has tried to implement something which really is against OO
| principles (so what's new here?).
what? would that be object ENCAPSULATION?!!! php is giving you the ability
to BOTH redefine objects you didn't author AND the ability to PROTECT the
ones that you have, should someone try to redefine it. the behavior is
optional. you should be happy with that.
btw, encapsulation is THE first PRIMARY directive in oop. so the 'what's new
here', i'd imagine, is that you still don't understand the ALTERNATE way
people see __set/__get. otherwise, you'd balk less...i would think.
| I've looked at it - but I really don't find it useful. This style is
| not implemented in other languages for very good reason - it really
| complicates the code, just as these functions do in PHP.
omg!
no, you're right...encapsulation is very low in importance. we should be
pissed that php gives us a means to protect the objects we create <sarcasm
of course>. i'm happy to accidentally misspell an interface name and not get
errors from php or the author, yet spend hours trying to figure out why the
value of the correct property is wrong. you're right, doing away with
__set/__get really does uncomplicate things.
what bowl were they hitt'n when they put that in there?!!!
I've been reading the responses eagerly and can appreciate all the
opinion. Truth is, I like the idea of being able to set a property
with:
$obj->prop = "a value";
That seems natural to me and I think it's going to be the option I
take........depending on the responses to my next question:
When properties are set, there'll be validation taking place. For
example a string might be too long or in the wrong format in which
case I need to let the user know that. Ideally the failure of
validation should allow the user to continue assigning values to other
properties and then once all the values are assigned, they can check
to see if there were any validation errors.
My first thought on this would be to have a "errors( )" method which
would return a reference to an array of error messages which the user
could then loop through and output to the browser. This same function
could again be used by "component" object when assigning the "item"
object to it to confirm it's valid.
Does this seem sensible?
Thanks,
Jimmy.
"Jim" <ji***@yahoo.comwrote in message
news:11**********************@d57g2000hsg.googlegr oups.com...
| I've been reading the responses eagerly and can appreciate all the
| opinion. Truth is, I like the idea of being able to set a property
| with:
|
| $obj->prop = "a value";
|
| That seems natural to me and I think it's going to be the option I
| take........depending on the responses to my next question:
yes, it is natural. however you cannot currently control the immediate
validation of the property being accessed. __set and __get do NOT do what
you think it does.
| When properties are set, there'll be validation taking place. For
| example a string might be too long or in the wrong format in which
| case I need to let the user know that. Ideally the failure of
| validation should allow the user to continue assigning values to other
| properties and then once all the values are assigned, they can check
| to see if there were any validation errors.
this is all common stuff that everyone wants/has to do. however, you cannot
do it immediately when a property is set, unless you use a public setter.
| My first thought on this would be to have a "errors( )" method which
| would return a reference to an array of error messages which the user
| could then loop through and output to the browser. This same function
| could again be used by "component" object when assigning the "item"
| object to it to confirm it's valid.
|
| Does this seem sensible?
all of it is very sensible. i just wish __set and __get would work on
DEFINED properties instead of UNDEFINED properties of a class.
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:PI******************************@comcast.com. ..
Vince Morgan wrote:
"Steve" <no****@example.comwrote in message
news:zG****************@newsfe12.lga...
You are undoubtedly aware that this has to be the most misunderstood
behaviour in all of php. Perhaps in all programing in all languages!!
The
number of posts I've read in the last few hours that clearly
misunderstand
_set() and __get() is astonishing! And all I've gleened from them was
further misunderstanding. Cant blame them realy. You have been trying
to
hammer the point home but the nails have just kept bending. I don't
think
I've ever been so confused about anything in my life.
Thank you!!
You have my undying grattitude Steve! :)))
Vince
Vince,
It's probably misunderstood because it's pretty much a violation of OO
principles. OO principles indicate you can set and get values - but
that you have separate setter and getter functions for these.
Now you can emulate this in other OO languages such as Java, C++ and
SmallTalk. But it's pretty much frowned upon. Experienced programmers
in these languages pretty much follow the defacto standard to have
separate getter and setter functions of each value you want to be able
to change/retrieve.
Doing it other ways just gets into too much of a hassle.
Now PHP has tried to implement something which really is against OO
principles (so what's new here?).
I've looked at it - but I really don't find it useful. This style is
not implemented in other languages for very good reason - it really
complicates the code, just as these functions do in PHP.
I know I don't have to tell you that it certainly confused me. I was quite
stunned when I first saw that you could add methods to a js object.
However, as you don't have access to the source of those classes I can
understand why some consider it a whorthwhile feature.
However, in the case of php where you do have such access it seems ludicrous
to me to do such a thing. If someone wants to add additional functionality
to a php object, why not simply write it into the class? Treating them as
if they are compiled objects seems more than a little silly to me.
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46***********************@news.optusnet.com.a u...
|
| "Jerry Stuckle" <js*******@attglobal.netwrote in message
| news:PI******************************@comcast.com. ..
| Vince Morgan wrote:
| "Steve" <no****@example.comwrote in message
| news:zG****************@newsfe12.lga...
| You are undoubtedly aware that this has to be the most misunderstood
| behaviour in all of php. Perhaps in all programing in all languages!!
| The
| number of posts I've read in the last few hours that clearly
| misunderstand
| _set() and __get() is astonishing! And all I've gleened from them was
| further misunderstanding. Cant blame them realy. You have been trying
| to
| hammer the point home but the nails have just kept bending. I don't
| think
| I've ever been so confused about anything in my life.
| Thank you!!
| You have my undying grattitude Steve! :)))
| Vince
|
|
| >
| Vince,
| >
| It's probably misunderstood because it's pretty much a violation of OO
| principles. OO principles indicate you can set and get values - but
| that you have separate setter and getter functions for these.
| >
| Now you can emulate this in other OO languages such as Java, C++ and
| SmallTalk. But it's pretty much frowned upon. Experienced programmers
| in these languages pretty much follow the defacto standard to have
| separate getter and setter functions of each value you want to be able
| to change/retrieve.
| >
| Doing it other ways just gets into too much of a hassle.
| >
| Now PHP has tried to implement something which really is against OO
| principles (so what's new here?).
| >
| I've looked at it - but I really don't find it useful. This style is
| not implemented in other languages for very good reason - it really
| complicates the code, just as these functions do in PHP.
| >
|
| I know I don't have to tell you that it certainly confused me. I was
quite
| stunned when I first saw that you could add methods to a js object.
| However, as you don't have access to the source of those classes I can
| understand why some consider it a whorthwhile feature.
| However, in the case of php where you do have such access it seems
ludicrous
| to me to do such a thing. If someone wants to add additional
functionality
| to a php object, why not simply write it into the class? Treating them as
| if they are compiled objects seems more than a little silly to me.
oh you do have access to the source of those classes. you can document.write
an entire js class if you wanted to...using alert none-the-less. even make a
prototype and forget whether the rhs assignment for a function should be
just the name or the name plus () ? figure out which is which and you've now
hacked how to get the source of custom objects.
as for php, you can just as easily make properties and functions and put
them into a custom class that you didn't author. __set/__get would help
prevent this...if you threw errors in your object to detect when this was
attempted.
it doesn't matter, to me, whether php objects are compiled or scripted. what
should be important is that objects are able to maintain their encapsulation
(if the author chooses to enforce it)...which is what __set/__get does. what
php is lacking is the default ability to assign private getters/setters to
properties such that:
$foo->bar = 'hello world';
would trigger bar's setter in your object's code. this is present in may
scripted languages and manditory for compiled languages like object c, c++,
c#, vb/.net, etc.
but anywho. :)
"Steve" <no****@example.comwrote in message
news:VR*************@newsfe04.lga...
>
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46***********************@news.optusnet.com.a u...
|
| "Jerry Stuckle" <js*******@attglobal.netwrote in message
| news:PI******************************@comcast.com. ..
| Vince Morgan wrote:
| "Steve" <no****@example.comwrote in message
| news:zG****************@newsfe12.lga...
| You are undoubtedly aware that this has to be the most misunderstood
| behaviour in all of php. Perhaps in all programing in all
languages!!
| The
| number of posts I've read in the last few hours that clearly
| misunderstand
| _set() and __get() is astonishing! And all I've gleened from them
was
| further misunderstanding. Cant blame them realy. You have been
trying
| to
| hammer the point home but the nails have just kept bending. I don't
| think
| I've ever been so confused about anything in my life.
| Thank you!!
| You have my undying grattitude Steve! :)))
| Vince
|
|
| >
| Vince,
| >
| It's probably misunderstood because it's pretty much a violation of OO
| principles. OO principles indicate you can set and get values - but
| that you have separate setter and getter functions for these.
| >
| Now you can emulate this in other OO languages such as Java, C++ and
| SmallTalk. But it's pretty much frowned upon. Experienced
programmers
| in these languages pretty much follow the defacto standard to have
| separate getter and setter functions of each value you want to be able
| to change/retrieve.
| >
| Doing it other ways just gets into too much of a hassle.
| >
| Now PHP has tried to implement something which really is against OO
| principles (so what's new here?).
| >
| I've looked at it - but I really don't find it useful. This style is
| not implemented in other languages for very good reason - it really
| complicates the code, just as these functions do in PHP.
| >
|
| I know I don't have to tell you that it certainly confused me. I was
quite
| stunned when I first saw that you could add methods to a js object.
| However, as you don't have access to the source of those classes I can
| understand why some consider it a whorthwhile feature.
| However, in the case of php where you do have such access it seems
ludicrous
| to me to do such a thing. If someone wants to add additional
functionality
| to a php object, why not simply write it into the class? Treating them
as
| if they are compiled objects seems more than a little silly to me.
oh you do have access to the source of those classes. you can
document.write
an entire js class if you wanted to...using alert none-the-less. even make
a
prototype and forget whether the rhs assignment for a function should be
just the name or the name plus () ? figure out which is which and you've
now
hacked how to get the source of custom objects.
as for php, you can just as easily make properties and functions and put
them into a custom class that you didn't author. __set/__get would help
prevent this...if you threw errors in your object to detect when this was
attempted.
it doesn't matter, to me, whether php objects are compiled or scripted.
what
should be important is that objects are able to maintain their
encapsulation
(if the author chooses to enforce it)...which is what __set/__get does.
what
php is lacking is the default ability to assign private getters/setters to
properties such that:
$foo->bar = 'hello world';
would trigger bar's setter in your object's code. this is present in may
scripted languages and manditory for compiled languages like object c,
c++,
c#, vb/.net, etc.
but anywho. :)
I agree. I can't see anything bad with being able to implement private
getters that are called in the fashion you've just described Steve.
In fact it is very attractive to me. I implement operator overloads in C++
as often as practical, and your proposed usage can emulate that to some
degree. In fact I was a little disapointed when I first looked at php that
it didn't have operator overloading.
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46***********************@news.optusnet.com.a u...
| "Steve" <no****@example.comwrote in message
| news:VR*************@newsfe04.lga...
| >
| "Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
| news:46***********************@news.optusnet.com.a u...
| |
| | "Jerry Stuckle" <js*******@attglobal.netwrote in message
| | news:PI******************************@comcast.com. ..
| | Vince Morgan wrote:
| | "Steve" <no****@example.comwrote in message
| | news:zG****************@newsfe12.lga...
| | You are undoubtedly aware that this has to be the most
misunderstood
| | behaviour in all of php. Perhaps in all programing in all
| languages!!
| | The
| | number of posts I've read in the last few hours that clearly
| | misunderstand
| | _set() and __get() is astonishing! And all I've gleened from them
| was
| | further misunderstanding. Cant blame them realy. You have been
| trying
| | to
| | hammer the point home but the nails have just kept bending. I
don't
| | think
| | I've ever been so confused about anything in my life.
| | Thank you!!
| | You have my undying grattitude Steve! :)))
| | Vince
| |
| |
| | >
| | Vince,
| | >
| | It's probably misunderstood because it's pretty much a violation of
OO
| | principles. OO principles indicate you can set and get values - but
| | that you have separate setter and getter functions for these.
| | >
| | Now you can emulate this in other OO languages such as Java, C++ and
| | SmallTalk. But it's pretty much frowned upon. Experienced
| programmers
| | in these languages pretty much follow the defacto standard to have
| | separate getter and setter functions of each value you want to be
able
| | to change/retrieve.
| | >
| | Doing it other ways just gets into too much of a hassle.
| | >
| | Now PHP has tried to implement something which really is against OO
| | principles (so what's new here?).
| | >
| | I've looked at it - but I really don't find it useful. This style
is
| | not implemented in other languages for very good reason - it really
| | complicates the code, just as these functions do in PHP.
| | >
| |
| | I know I don't have to tell you that it certainly confused me. I was
| quite
| | stunned when I first saw that you could add methods to a js object.
| | However, as you don't have access to the source of those classes I can
| | understand why some consider it a whorthwhile feature.
| | However, in the case of php where you do have such access it seems
| ludicrous
| | to me to do such a thing. If someone wants to add additional
| functionality
| | to a php object, why not simply write it into the class? Treating
them
| as
| | if they are compiled objects seems more than a little silly to me.
| >
| oh you do have access to the source of those classes. you can
| document.write
| an entire js class if you wanted to...using alert none-the-less. even
make
| a
| prototype and forget whether the rhs assignment for a function should be
| just the name or the name plus () ? figure out which is which and you've
| now
| hacked how to get the source of custom objects.
| >
| as for php, you can just as easily make properties and functions and put
| them into a custom class that you didn't author. __set/__get would help
| prevent this...if you threw errors in your object to detect when this
was
| attempted.
| >
| it doesn't matter, to me, whether php objects are compiled or scripted.
| what
| should be important is that objects are able to maintain their
| encapsulation
| (if the author chooses to enforce it)...which is what __set/__get does.
| what
| php is lacking is the default ability to assign private getters/setters
to
| properties such that:
| >
| $foo->bar = 'hello world';
| >
| would trigger bar's setter in your object's code. this is present in may
| scripted languages and manditory for compiled languages like object c,
| c++,
| c#, vb/.net, etc.
| >
| but anywho. :)
| >
| I agree. I can't see anything bad with being able to implement private
| getters that are called in the fashion you've just described Steve.
| In fact it is very attractive to me. I implement operator overloads in C++
| as often as practical, and your proposed usage can emulate that to some
| degree. In fact I was a little disapointed when I first looked at php
that
| it didn't have operator overloading.
you'd think they would be able to fairly easily too. it's not hard to get a
function's signature. and, they are already giving the ability to just throw
interfaces in willie-nilly. putting some structure and rules around all that
would probably get it there. i think just about the only requirement on the
developer's end of things would be to stongly type a function's parameters
so php would know what the signature looked like...$foo->bar(string param)
vs. $foo->bar(int param), etc.
maybe in the future.
keep 'em rock'n.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Dave Smithz |
last post by:
Having adopted someone else's PHP cope and completing a crash course in the
language I came across a (probably common) problem with the current code.
On a registration form, whenever users names...
|
by: Aadam |
last post by:
Does Microsoft have a best practices for tracking errors? (like in a
database, what info, etc)
|
by: Jon Rea |
last post by:
I am currently cleaning up an application which was origainlly hashed
together with speed of coding in mind and therefore contains quite a few
"hacky" shortcuts.
As part of this "revamping"...
|
by: Barry Morris |
last post by:
Hi
I am a php newbie although I have been a programmer for years, this can be
dangerous because all the languages I know use = as equal comparison so it
took me a long time to debug if ($STRING...
|
by: cbrown |
last post by:
I am rebuilding an existing application that relies on an SQL DB. The
app is a scheduling/employee management program. My question pertains
to best practices in dotnet and database.
I use a 3...
|
by: bonk |
last post by:
I have come across the need to distinguish between the creation of a
deep and a shallow copy and with great interest I have read this
article:
...
|
by: Ned Balzer |
last post by:
Hi all,
I am pretty new to asp.net; I've done lots of classic asp, but am just
beginning to get my mind wrapped around .net.
What I'd like to do is include some code that tests if a user is...
|
by: =?Utf-8?B?VzFsZDBuZTc0?= |
last post by:
When one architects a new project one of the first steps in the decision is
to decide on the layers. (In my opinion anyway)
One architecture that I have used before is to go solid OO and create...
|
by: Paul |
last post by:
Hi,
I feel I'm going around circles on this one and would appreciate some other
points of view.
From a design / encapsulation point of view, what's the best practise for
returning a private...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: giovanniandrean |
last post by:
The energy model is structured as follows and uses excel sheets to give input data:
1-Utility.py contains all the functions needed to calculate the variables and other minor things (mentions...
|
by: NeoPa |
last post by:
Hello everyone.
I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report).
I know it can be done by selecting :...
|
by: Teri B |
last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course.
0ne-to-many. One course many roles.
Then I created a report based on the Course form and...
|
by: nia12 |
last post by:
Hi there,
I am very new to Access so apologies if any of this is obvious/not clear.
I am creating a data collection tool for health care employees to complete. It consists of a number of...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be focusing on the Report (clsReport) class. This simply handles making the calling Form invisible until all of the Reports opened by it have been closed, when it...
|
by: isladogs |
last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, Mike...
|
by: GKJR |
last post by:
Does anyone have a recommendation to build a standalone application to replace an Access database? I have my bookkeeping software I developed in Access that I would like to make available to other...
| |
