On Fri, 2010-04-23 at 19:03 +0200, Peter Lind wrote: > On 23 April 2010 18:26, Ashley Sheridan <a...@ashleysheridan.co.uk> 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.l...@gmail.com> wrote: > > > > > On 23 April 2010 18:10, Ashley Sheridan <a...@ashleysheridan.co.uk> 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
