Re: public readonly variables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2010-04-23 at 19:03 +0200, Peter Lind wrote:

> On 23 April 2010 18:26, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Fri, 2010-04-23 at 12:25 -0400, Adam Richardson wrote:
> >
> > On Fri, Apr 23, 2010 at 12:21 PM, Peter Lind <peter.e.lind@xxxxxxxxx> wrote:
> >
> > > On 23 April 2010 18:10, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx> wrote:
> > > > I think for now I'll just resort to leaving it as a public variable.
> > > > I'll leave the specific set function for it in and just hope that is
> > > > used instead! As it's only me who'll be using it for the time being, I
> > > > can always yell at myself later if I forget!
> > >
> > > You're using a setter but a public variable? That's about the worst
> > > compromise, isn't it? Either go down the road of the public variable
> > > or the setter/getter (and in your case I would definitely recommend
> > > the latter). Also, __get/__set are fine, as long as you don't use them
> > > for everything (i.e. 5 magic calls per request will do very, very
> > > little to your app, whereas 1000 per request will have some
> > > significance on a site with lots of users).
> > >
> > > Regards
> > > Peter
> > >
> > > --
> > > <hype>
> > > WWW: http://plphp.dk / http://plind.dk
> > > LinkedIn: http://www.linkedin.com/in/plind
> > > Flickr: http://www.flickr.com/photos/fake51
> > > BeWelcome: Fake51
> > > Couchsurfing: Fake51
> > > </hype>
> > >
> >
> > I agree with Peter, that solutions asks for trouble (something I often do,
> > but avoid publicly advocating ;)
> >
> > The solution I suggested still maintains all of the documentation
> > capabilities (at least in my NetBeans), but enforces protection.  It's not
> > perfect, but it does work relatively well.
> >
> > Adam
> >
> >
> > I am probably looking at a lot of getters in the code though, so the overhead I'd rather avoid. The setter is to go some way towards keeping the values sane, which I realise goes against the whole public variable thing, which is the reason for my original question.
> >
> > Another reason for the setter is that it actually modifies a couple of variables, so there's no good way of getting rid of that, as it would then mean setting two properties of the object manually, which would actually lead to more issues down the line if not set correctly.
> >
> 
> If you're just creating the project now, I'd autogenerate the classes,
> to avoid the manual work. Otherwise, I'd give it some long thought
> then grit my teeth and dig in.
> 
> Regards
> Peter
> 
> 
> --
> <hype>
> WWW: http://plphp.dk / http://plind.dk
> LinkedIn: http://www.linkedin.com/in/plind
> Flickr: http://www.flickr.com/photos/fake51
> BeWelcome: Fake51
> Couchsurfing: Fake51
> </hype>


I will be auto-generating the objects, but I'm not sure what you mean by
auto-generating the classes?

Thanks,
Ash
http://www.ashleysheridan.co.uk



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux