where is this project going?

[mindplay.dk]

Hi,

Just out of curiosity. The initial releases of version 1 had a nice,
lightweight design and compact code.

I've been looking at version 2, and I see classes like this one:

https://github.com/lcobucci/outlet-orm/blob/svn-trunk/application/org.outlet-orm/entity/OutletEntityProperty.php

What exactly is the point of code like this?

A whole bunch of redundant get and set accessors that don't do
anything, beyond simply getting or setting a private variable.

class Test
{
private $value;

public function setValue($value)
{
$this->value = $value;
}

public function getValue()
{
return $this->value;
}
}

This is obviously the exact equivalent of:

class Test
{
public $value;
}

The main difference is, 10 times more code to maintain (and load/
parse) and the added overhead of 10 function calls every time you
construct one of these instead of just one.

Somebody's been spending too much time programming in C# lately? I
mean, I know *I* have - but I ain't THAT far gone! wtf?? :-)

It does not look like version 2 is going to be as slick, compact and
efficient as version 1, by any means...

Just my two cents.

[Luís Otávio]

Hi!

 

That repo that you are talking about is not the oficial one, its my fork.

I use getters and setters pattern to encapsulate the stuffs, do data validation, etc.

 

As I said before my refactoring process is not even 40% complete.

I don't wanna say to everybody use my fork, I just doing what I think is right: share the code that I wrote.

 

The use of getters and setters is really personal, but TO ME makes the code more extensible.

 

I have run a lot of tests and with my version of Outlet the framework is a little bit faster... But anyway... Thats not the version 2 of Outlet, its just a bunch of code writen by a crazy programmer that just want to share.

 

As I said before, if you want to use go ahead... and I add a little thing: if you like something but hatted other things, create a fork and help to improve even more... but *DO SOMETHING*!!! =D

 

And no, I'm not a C# programmer. lol

 

Luís

--
You received this message because you are subscribed to the Google Groups "Outlet ORM" group.
To post to this group, send email to outle...@googlegroups.com.
To unsubscribe from this group, send email to outlet-orm+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/outlet-orm?hl=en.

[Judd Pickell]

I feel a bit confused. Patterns are required for development beyond just personal use. Integration and unintended uses are so much easier when Patterns are followed and used. Sure sometimes it can feel like more code, but in the long run it is so much easier to know where to look for problems, gives you plenty of hook points for debugging, etc. It is far easier to debug a set if you have a function you are using than just a straight $this->var = value; everywhere.

Just because you can do something in one line doesn't make it be best way.. Oh the heady days of Perl.. ;)

Have you actually done a time test to see if the extra is actually that much worse? or if the difference is negligble? Personally on the enterprise hardware at work, there would literally be no difference in time I am sure. Those machines are beastly.

Sincerely,

Judd Pickell

[mindplay.dk]

Ah - I didn't realize this wasn't the official "next generation" of
Outlet...

Generally I agree with most of what you've done. But I don't generally
see the need for redundant public property accessors, unless they're
doing something - from the user code perspective, you could use
accessors or not, the user code would look the same. $object->property
works equally well whether it's declared as public $property or a pair
of accessor, does it not? I don't see the need for a pair of
accessors, unless they add some kind of benefit, for example type
checking and throwing an exception, which makes it easier to debug -
if something accepts a number or a bool, for example, I generally
write accessors and perform validation in the writer-method.

Anyways, different folks, different strokes :-)

Under any circumstances, I generally like what you're doing, and maybe
I should have pointed that out instead of just criticizing. Sorry
about that.

On Nov 13, 8:19 am, Luís Otávio <lcobu...@gmail.com> wrote:
> Hi!
>
> That repo that you are talking about is not the oficial one, its my fork.
> I use getters and setters pattern to encapsulate the stuffs, do data
> validation, etc.
>
> As I said before my refactoring process is not even 40% complete.
> I don't wanna say to everybody use my fork, I just doing what I think is
> right: share the code that I wrote.
>
> The use of getters and setters is really personal, but TO ME makes the code
> more extensible.
>
> I have run a lot of tests and with my version of Outlet the framework is a
> little bit faster... But anyway... Thats not the version 2 of Outlet, its
> just a bunch of code writen by a crazy programmer that just want to share.
>
> As I said before, if you want to use go ahead... and I add a little thing:
> if you like something but hatted other things, create a fork and help to
> improve even more... but *DO SOMETHING*!!! =D
>
> And no, I'm not a C# programmer. lol
>
> Luís
>
>
>
>
>
>
>
> On Fri, Nov 12, 2010 at 11:19 PM, mindplay.dk <ras...@mindplay.dk> wrote:
> > Hi,
>
> > Just out of curiosity. The initial releases of version 1 had a nice,
> > lightweight design and compact code.
>
> > I've been looking at version 2, and I see classes like this one:
>

> >https://github.com/lcobucci/outlet-orm/blob/svn-trunk/application/org...

> > outlet-orm+...@googlegroups.com<outlet-orm%2Bunsubscribe@googlegrou ps.com>
> > .

[mindplay.dk]

> Have you actually done a time test to see if the extra is actually that much
> worse? or if the difference is negligble? Personally on the enterprise
> hardware at work, there would literally be no difference in time I am sure.

I haven't benchmarked this project specifically - but yes, and
granted, I am a bit of a performance freak, and I have written
benchmarks for lots of different patterns in PHP to get a feel for the
performance / maintainability trade-off...

I have certainly benchmarked accessors vs properties, and they do add
significant overhead when compared relative to each other. Kind of
goes without saying - two function calls for every property read or
write, vs simple property access... inevitably this adds significant
overhead.

Relative to each other, that is. In the grand scheme of things, and
particularly in the case of an ORM, the overhead of actually
performing database queries is generally large enough to dwarf the
added overhead of using accessors.

Thinking into the future though, I'm really interested in using
OrientDB in PHP - since document/graph stores are orders of magnitude
faster than SQL queries, the added overhead seems more significant.

That's my thinking ahead though, and probably not relevant for
Outlet...

[Luís Otávio]

I gotta say sorry too... I was a little bit rude.

I'm just tired of people that just complains about the stuffs and don't help to make it better.

And we all know that PHP community has a lot of those kind of people... lol

 

Well, I agree with you, and yes calling a method just to get a property has an overhead.

The purpose of the accessors on my code is to do data validation and throw some exceptions, but I've made a big change on Outlet's architeture and I was concerned to make it work.

 

Well now let me anwser your original question "where is this project going?" (from a different perspective hehehe):

 

I built this fork to share the code that I created on my company, we started to use Outlet last year and I've made some changes to solve some issues.

Now I got some stuffs that I need to change on Outlet to add some funcionalities, like:

 

- More than 1 config (I got on my company a lot of projects that uses Outlet, but now I have 1 that has to use others. I know that I can just create a service - SOAP, REST, ... - but I think that will create an overhead, I can just include them on include_path and use the classes. So I decided that I will make that change)

- Entity config by demand (if we got a lot of entities and a request just use 3 of them why do we have to create the configuration of all entities, that can be painfull for memory)
- Config by annotations (that would be very easy to config, theres a project named addendum http://code.google.com/p/addendum/ that can help a lot)

 

Thats the start... and of course, finish the refactoring process, create more unit tests and PHPDoc.

 

If someone wishes to help please let me know!

 

Luís

To unsubscribe from this group, send email to outlet-orm+...@googlegroups.com.

[kelly]

I've been starting to use the convention of having a getter and setter
in one function:

class User {

private $name;

public function name($name = null) {

if($name === null) {
return $this->name;
}
$this->name = $name;

}

}

It has the added if-then check, but that's not really even an issue.
It's all personal preference, honestly, but i think shorter
conventions are better.

> named addendumhttp://code.google.com/p/addendum/that can help a lot)

> > > > outlet-orm+...@googlegroups.com<outlet-orm%2Bunsu...@googlegroups.com>

> > <outlet-orm%2Bunsubscribe@googlegrou ps.com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/outlet-orm?hl=en.
>
> > --
> >  You received this message because you are subscribed to the Google Groups
> > "Outlet ORM" group.
> > To post to this group, send email to outle...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > outlet-orm+...@googlegroups.com<outlet-orm%2Bunsu...@googlegroups.com>