I understand what your saying, however I guess I see the tradeoff of creating a new reserved word to a (IMHO of course) kinda messy new syntax a good one.
Besides, having an absolute standard for get/set would be benefital to all developers.. Knowing that setting $foo is always setfoo() (or set_foo(), makes no difference) would be nice. As for assuming the user knows how the syntax works, that'd be the same thing with any new syntax at all... John |-----Original Message----- |From: Alan Knowles [mailto:alan@;akbkhome.com] |Sent: Wednesday, November 13, 2002 12:10 AM |To: John Coggeshall |Cc: [EMAIL PROTECTED] |Subject: Re: [PHP-DEV] prototypes for getters and setters. | | |the trouble is that you will make pubvar a reserved word, and |you force |the user to use a fixed standard for set/get -- eg. some users |may like |get_orange, others may want getOrange.... |It also makes the assumtion that the user knows how the syntax |works.. - |eg. searching the file for getOrange would return nothing... | |Regards |Alan | |John Coggeshall wrote: | |>What about something like this... |> |>Class foo { |> |> var $myfoo; // "Private" variable |> pubvar $myfoo2; // "Public" variable |> |> |>} |> |>Class bar extends foo { |> |> pubvar $mystuff; |> |>} |> |>$a = new foo(); |>$a->setmyfoo2(5); |>echo $a->getmyfoo2(); |> |>$b = new bar(); |>$b->setmyfoo2(10); |>$b->setmystuff(20); |> |>The point here is that pubvar automatically creates get* and |set*.. As |>far as overloading, etc is concerned, there would be no need to worry |>about it -- the point of these functions is not to overload |them (they |>should simply be used to get and set member variables)... |> |>John |> |>|-----Original Message----- |>|From: Shane Caraveo [mailto:shane@;caraveo.com] |>|Sent: Tuesday, November 12, 2002 10:04 PM |>|To: Alan Knowles |>|Cc: [EMAIL PROTECTED] |>|Subject: Re: [PHP-DEV] prototypes for getters and setters. |>| |>| |>|Alan Knowles wrote: |>| |>|> Shane Caraveo wrote: |>|> |>|> >> |>|> >> |>|> >> Anyway before I get carried away and actually test this :) - |>|> anybody got |>|> >> any thoughts..... |>|> >> |>|> >> Regards |>|> >> Alan |>|> > |>|> > |>|> > |>|> > |>|> > What's wrong with how overload does this? |>|> |>|> |>|> it has a slight downside in clarity of code - eg. where is that |>|> method.. |>|> |>|But it (overload) also does not introduce new syntax, requires no |>|changes to the engine, is genericly overrideable in extensions, etc. |>|etc. etc. |>| |>|Shane |>| |>| |>|-- |>|PHP Development Mailing List <http://www.php.net/> |>|To unsubscribe, visit: http://www.php.net/unsub.php |>| |>| |> |> |> |> | | | -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
