librelist archives

« back to archive

Minimal user object requirements

Minimal user object requirements

From:
Loic d'Anterroches
Date:
2011-03-24 @ 12:38
Hello,

this one is a hard one. What do we put in the minimal user? When you
look at the Django user object or the Symfony user interfaces, you have
to provide a lot of things. Way more than what I am comfortable dealing
with.

So, here are the properties of a user object in Photon:

# login

a unique for the user id. It can be anything, it just needs to be
unique. By convention, it is name login as most of the time you give
your users a login. But it could be a ssh public key.

# is_anonymous

boolean, normally false. The photon\auth\AnonymousUser has it set to
true, of course.

# password

because most of the time you will authenticate with a password. Just set
it to an empty string if you do not use it. Password are always
encrypted with bcrypt with at the moment a '07' work factor. Using a
salted sha1 storage is not anymore good enough. Here is an example of
hashed password ('secret'):

'$2a$07$BBNZk0uLBsZRWPhSPyn61OqWJM9opNUEoeryF26SmRGMgXU/iFH3.'

You can easiyl get the hash with the right salt and right work factor by
calling: $hash = \photon\crypto\Hash::hashPass('secret')

Some remarks:

- yes, no interfaces, no methods. Just some properties. Each backend can
require more properties, but this is up to them. For example, at the
moment, I work on a Yubikey authentication backend and I require a
yubikey_id property.
- a couple properties will most likely be added, but not be required:
language, is_active, name, email, timezone.

Would you consider ok to have a kind of base class \photon\auth\User
that you can extend, reuse for your own users?

I am a bit reluctant to provide a ready to use class because it may end
up being a defacto standard and people may start to code with the
assumption that a user is represented by this given class. So... I am
not sure.

Feedback welcome. What are the properties you *need* for your users?

loïc

--
Indefero - Project management and code hosting - http://www.indefero.net
Photon - High Performance PHP Framework - http://photon-project.com
Céondo Ltd - Web + Science = Fun - http://www.ceondo.com

Re: [photon.users] Minimal user object requirements

From:
Mickaël Desfrênes
Date:
2011-03-24 @ 13:18
As long as it's backend-independent...

2011/3/24 Loic d'Anterroches <loic@ceondo.com>

> Hello,
>
> this one is a hard one. What do we put in the minimal user? When you
> look at the Django user object or the Symfony user interfaces, you have
> to provide a lot of things. Way more than what I am comfortable dealing
> with.
>
> So, here are the properties of a user object in Photon:
>
> # login
>
> a unique for the user id. It can be anything, it just needs to be
> unique. By convention, it is name login as most of the time you give
> your users a login. But it could be a ssh public key.
>
> # is_anonymous
>
> boolean, normally false. The photon\auth\AnonymousUser has it set to
> true, of course.
>
> # password
>
> because most of the time you will authenticate with a password. Just set
> it to an empty string if you do not use it. Password are always
> encrypted with bcrypt with at the moment a '07' work factor. Using a
> salted sha1 storage is not anymore good enough. Here is an example of
> hashed password ('secret'):
>
> '$2a$07$BBNZk0uLBsZRWPhSPyn61OqWJM9opNUEoeryF26SmRGMgXU/iFH3.'
>
> You can easiyl get the hash with the right salt and right work factor by
> calling: $hash = \photon\crypto\Hash::hashPass('secret')
>
> Some remarks:
>
> - yes, no interfaces, no methods. Just some properties. Each backend can
> require more properties, but this is up to them. For example, at the
> moment, I work on a Yubikey authentication backend and I require a
> yubikey_id property.
> - a couple properties will most likely be added, but not be required:
> language, is_active, name, email, timezone.
>
> Would you consider ok to have a kind of base class \photon\auth\User
> that you can extend, reuse for your own users?
>
> I am a bit reluctant to provide a ready to use class because it may end
> up being a defacto standard and people may start to code with the
> assumption that a user is represented by this given class. So... I am
> not sure.
>
> Feedback welcome. What are the properties you *need* for your users?
>
> loïc
>
> --
> Indefero - Project management and code hosting - http://www.indefero.net
> Photon - High Performance PHP Framework - http://photon-project.com
> Céondo Ltd - Web + Science = Fun - http://www.ceondo.com
>



--

Re: [photon.users] Minimal user object requirements

From:
Loic d'Anterroches
Date:
2011-03-24 @ 13:32

On 2011-03-24 14:18, Mickaël Desfrênes wrote:
> As long as it's backend-independent...

It will always be. The goal with Photon is to be totally backend
independent at the framework level. If you then create applications
which require a given backend, fine, but Photon will never force you to
use one or another.

For example, I just created an authentication backend to use a yubikey
to login with the user list stored directly in the configuration file of
the project.

loïc

> 2011/3/24 Loic d'Anterroches <loic@ceondo.com <mailto:loic@ceondo.com>>
> 
>     Hello,
> 
>     this one is a hard one. What do we put in the minimal user? When you
>     look at the Django user object or the Symfony user interfaces, you have
>     to provide a lot of things. Way more than what I am comfortable dealing
>     with.
> 
>     So, here are the properties of a user object in Photon:
> 
>     # login
> 
>     a unique for the user id. It can be anything, it just needs to be
>     unique. By convention, it is name login as most of the time you give
>     your users a login. But it could be a ssh public key.
> 
>     # is_anonymous
> 
>     boolean, normally false. The photon\auth\AnonymousUser has it set to
>     true, of course.
> 
>     # password
> 
>     because most of the time you will authenticate with a password. Just set
>     it to an empty string if you do not use it. Password are always
>     encrypted with bcrypt with at the moment a '07' work factor. Using a
>     salted sha1 storage is not anymore good enough. Here is an example of
>     hashed password ('secret'):
> 
>     '$2a$07$BBNZk0uLBsZRWPhSPyn61OqWJM9opNUEoeryF26SmRGMgXU/iFH3.'
> 
>     You can easiyl get the hash with the right salt and right work factor by
>     calling: $hash = \photon\crypto\Hash::hashPass('secret')
> 
>     Some remarks:
> 
>     - yes, no interfaces, no methods. Just some properties. Each backend can
>     require more properties, but this is up to them. For example, at the
>     moment, I work on a Yubikey authentication backend and I require a
>     yubikey_id property.
>     - a couple properties will most likely be added, but not be required:
>     language, is_active, name, email, timezone.
> 
>     Would you consider ok to have a kind of base class \photon\auth\User
>     that you can extend, reuse for your own users?
> 
>     I am a bit reluctant to provide a ready to use class because it may end
>     up being a defacto standard and people may start to code with the
>     assumption that a user is represented by this given class. So... I am
>     not sure.
> 
>     Feedback welcome. What are the properties you *need* for your users?
> 
>     loïc
> 
>     --
>     Indefero - Project management and code hosting - http://www.indefero.net
>     Photon - High Performance PHP Framework - http://photon-project.com
>     Céondo Ltd - Web + Science = Fun - http://www.ceondo.com
> 
> 
> 
> 
> -- 
> 
> 

Re: [photon.users] Minimal user object requirements

From:
Mickaël Desfrênes
Date:
2011-03-24 @ 14:22
Good !

I use an ACL system that is backend independent:
https://github.com/desfrenes/Azuki/blob/master/plugins/Azuki/acl/Service.php

2011/3/24 Loic d'Anterroches <loic@ceondo.com>

>
>
> On 2011-03-24 14:18, Mickaël Desfrênes wrote:
> > As long as it's backend-independent...
>
> It will always be. The goal with Photon is to be totally backend
> independent at the framework level. If you then create applications
> which require a given backend, fine, but Photon will never force you to
> use one or another.
>
> For example, I just created an authentication backend to use a yubikey
> to login with the user list stored directly in the configuration file of
> the project.
>
> loïc
>
>

Re: [photon.users] Minimal user object requirements

From:
Loic d'Anterroches
Date:
2011-03-24 @ 15:17

On 2011-03-24 15:22, Mickaël Desfrênes wrote:
> Good !
> 
> I use an ACL system that is backend independent:
> https://github.com/desfrenes/Azuki/blob/master/plugins/Azuki/acl/Service.php

Yes, I went through your Azuki stuff. Nice and clean with label and
roles where I use permissions and groups but in concept, they are close
to each other.

At the moment, my main question is what kind of clean backend
independent interface I should have for the user storage. Of course, I
will need to implement example backend too.

loïc

> 2011/3/24 Loic d'Anterroches <loic@ceondo.com <mailto:loic@ceondo.com>>
> 
> 
> 
>     On 2011-03-24 14:18, Mickaël Desfrênes wrote:
>     > As long as it's backend-independent...
> 
>     It will always be. The goal with Photon is to be totally backend
>     independent at the framework level. If you then create applications
>     which require a given backend, fine, but Photon will never force you to
>     use one or another.
> 
>     For example, I just created an authentication backend to use a yubikey
>     to login with the user list stored directly in the configuration file of
>     the project.
> 
>     loïc
> 

Re: [photon.users] Minimal user object requirements

From:
nico
Date:
2011-03-24 @ 13:26
Hello,

As we're talking about a generic User class, I have a couple thoughts :

- The "login" property name sounds too specific to me. Not that it matters,
but I'd rather have it called it "id" since it's supposed to be used as a
user identifier.

- The default User class could be declared as abstract, so inheritance and
overloading would be mandatory. That way you can limit the properties in the
base (abstract) class to a bare minimum. That minimum would include an
identifier (login or id or whatever) and something to handle authentication
(the password property sounds just fine for that purpose). And the rest will
be app developpers' matter, according to their needs.

Cheers !
Nicolas


On Thu, Mar 24, 2011 at 1:38 PM, Loic d'Anterroches <loic@ceondo.com> wrote:

> Hello,
>
> this one is a hard one. What do we put in the minimal user? When you
> look at the Django user object or the Symfony user interfaces, you have
> to provide a lot of things. Way more than what I am comfortable dealing
> with.
>
> So, here are the properties of a user object in Photon:
>
> # login
>
> a unique for the user id. It can be anything, it just needs to be
> unique. By convention, it is name login as most of the time you give
> your users a login. But it could be a ssh public key.
>
> # is_anonymous
>
> boolean, normally false. The photon\auth\AnonymousUser has it set to
> true, of course.
>
> # password
>
> because most of the time you will authenticate with a password. Just set
> it to an empty string if you do not use it. Password are always
> encrypted with bcrypt with at the moment a '07' work factor. Using a
> salted sha1 storage is not anymore good enough. Here is an example of
> hashed password ('secret'):
>
> '$2a$07$BBNZk0uLBsZRWPhSPyn61OqWJM9opNUEoeryF26SmRGMgXU/iFH3.'
>
> You can easiyl get the hash with the right salt and right work factor by
> calling: $hash = \photon\crypto\Hash::hashPass('secret')
>
> Some remarks:
>
> - yes, no interfaces, no methods. Just some properties. Each backend can
> require more properties, but this is up to them. For example, at the
> moment, I work on a Yubikey authentication backend and I require a
> yubikey_id property.
> - a couple properties will most likely be added, but not be required:
> language, is_active, name, email, timezone.
>
> Would you consider ok to have a kind of base class \photon\auth\User
> that you can extend, reuse for your own users?
>
> I am a bit reluctant to provide a ready to use class because it may end
> up being a defacto standard and people may start to code with the
> assumption that a user is represented by this given class. So... I am
> not sure.
>
> Feedback welcome. What are the properties you *need* for your users?
>
> loïc
>
> --
> Indefero - Project management and code hosting - http://www.indefero.net
> Photon - High Performance PHP Framework - http://photon-project.com
> Céondo Ltd - Web + Science = Fun - http://www.ceondo.com
>

Re: [photon.users] Minimal user object requirements

From:
Loic d'Anterroches
Date:
2011-03-24 @ 13:37
Hello,

> - The "login" property name sounds too specific to me. Not that it
> matters, but I'd rather have it called it "id" since it's supposed to be
> used as a user identifier.

The thing is I don't know a single application not using a login. This
is why I am setting this one as a base property.

> - The default User class could be declared as abstract, so inheritance
> and overloading would be mandatory. That way you can limit the
> properties in the base (abstract) class to a bare minimum. That minimum
> would include an identifier (login or id or whatever) and something to
> handle authentication (the password property sounds just fine for that
> purpose). And the rest will be app developpers' matter, according to
> their needs.

Interesting, I have never been using the abstract stuff in my code, but
here it could make sense.

I will dig further.

Thanks for the feedback!
loïc

> 
> On Thu, Mar 24, 2011 at 1:38 PM, Loic d'Anterroches <loic@ceondo.com
> <mailto:loic@ceondo.com>> wrote:
> 
>     Hello,
> 
>     this one is a hard one. What do we put in the minimal user? When you
>     look at the Django user object or the Symfony user interfaces, you have
>     to provide a lot of things. Way more than what I am comfortable dealing
>     with.
> 
>     So, here are the properties of a user object in Photon:
> 
>     # login
> 
>     a unique for the user id. It can be anything, it just needs to be
>     unique. By convention, it is name login as most of the time you give
>     your users a login. But it could be a ssh public key.
> 
>     # is_anonymous
> 
>     boolean, normally false. The photon\auth\AnonymousUser has it set to
>     true, of course.
> 
>     # password
> 
>     because most of the time you will authenticate with a password. Just set
>     it to an empty string if you do not use it. Password are always
>     encrypted with bcrypt with at the moment a '07' work factor. Using a
>     salted sha1 storage is not anymore good enough. Here is an example of
>     hashed password ('secret'):
> 
>     '$2a$07$BBNZk0uLBsZRWPhSPyn61OqWJM9opNUEoeryF26SmRGMgXU/iFH3.'
> 
>     You can easiyl get the hash with the right salt and right work factor by
>     calling: $hash = \photon\crypto\Hash::hashPass('secret')
> 
>     Some remarks:
> 
>     - yes, no interfaces, no methods. Just some properties. Each backend can
>     require more properties, but this is up to them. For example, at the
>     moment, I work on a Yubikey authentication backend and I require a
>     yubikey_id property.
>     - a couple properties will most likely be added, but not be required:
>     language, is_active, name, email, timezone.
> 
>     Would you consider ok to have a kind of base class \photon\auth\User
>     that you can extend, reuse for your own users?
> 
>     I am a bit reluctant to provide a ready to use class because it may end
>     up being a defacto standard and people may start to code with the
>     assumption that a user is represented by this given class. So... I am
>     not sure.
> 
>     Feedback welcome. What are the properties you *need* for your users?
> 
>     loïc
> 
>     --
>     Indefero - Project management and code hosting - http://www.indefero.net
>     Photon - High Performance PHP Framework - http://photon-project.com
>     Céondo Ltd - Web + Science = Fun - http://www.ceondo.com
> 
> 

Re: [photon.users] Minimal user object requirements

From:
nico
Date:
2011-03-24 @ 14:01
On Thu, Mar 24, 2011 at 2:37 PM, Loic d'Anterroches <loic@ceondo.com> wrote:

> - The "login" property name sounds too specific to me. Not that it
> > matters, but I'd rather have it called it "id" since it's supposed to be
> > used as a user identifier.
>
> The thing is I don't know a single application not using a login. This
> is why I am setting this one as a base property.
>

Well, an application relying on a remotely-stored user (Facebook apps for
instance) will most likely store a user id, and  use it as the user
identifier property. Every other data provided by the remote service will be
used as labels. This is mostly because these properties are managed remotely
and could change over time.

The "login" property can obviously be used to store an id, but the name
doesn't seem adapted to the usage.

I'm currently working on such an application, and the scheme you're
describing doesn't seem to exactly fit my needs. I don't mind adapting my
code to the framework needs, but I want to provide you with my thoughts on
that matter, so you can include various contexts in your analysis.

Cheers!
Nicolas

Re: [photon.users] Minimal user object requirements

From:
Loic d'Anterroches
Date:
2011-03-24 @ 14:03

On 2011-03-24 15:01, nico wrote:
> On Thu, Mar 24, 2011 at 2:37 PM, Loic d'Anterroches <loic@ceondo.com
> <mailto:loic@ceondo.com>> wrote:
> 
>     > - The "login" property name sounds too specific to me. Not that it
>     > matters, but I'd rather have it called it "id" since it's supposed
>     to be
>     > used as a user identifier.
> 
>     The thing is I don't know a single application not using a login. This
>     is why I am setting this one as a base property.
> 
> 
> Well, an application relying on a remotely-stored user (Facebook apps
> for instance) will most likely store a user id, and  use it as the user
> identifier property. Every other data provided by the remote service
> will be used as labels. This is mostly because these properties are
> managed remotely and could change over time.
> 
> The "login" property can obviously be used to store an id, but the name
> doesn't seem adapted to the usage.
> 
> I'm currently working on such an application, and the scheme you're
> describing doesn't seem to exactly fit my needs. I don't mind adapting
> my code to the framework needs, but I want to provide you with my
> thoughts on that matter, so you can include various contexts in your
> analysis.

Do you have an example in "pseudo" code. I have never done this, so a
small example would help me understand the situation.

thanks!
loïc

Re: [photon.users] Minimal user object requirements

From:
nico
Date:
2011-03-24 @ 14:51
>
> > Well, an application relying on a remotely-stored user (Facebook apps
> > for instance) will most likely store a user id, and  use it as the user
> > identifier property. Every other data provided by the remote service
> > will be used as labels. This is mostly because these properties are
> > managed remotely and could change over time.
>
> Do you have an example in "pseudo" code. I have never done this, so a
> small example would help me understand the situation.
>

Here is how it works :

1- A user "installs" your application on Facebook
It means he accesses it for the first time, and is prompted to accept to
share some data with your application. He answers yes and is now registered
as a user for your application.

2- The user accesses your application
The screens of your application are accessed by Facebook. Literally, the
user stays on the facebook.com domain, and FB acts as a proxy, forwarding
the requests to the corresponding pages. These requests include various data
(available in $_POST), and particularly the current user id, which is
described by FB as the universal identifier for a User registered on FB. It
might also include the user's friend's ids.

3- Your app does what it has to do
Your app does it's magic, perhaps making FB API calls to get personal
informations about the user (name, status, events, ...) always using the
user id. In the end your app generates the content that is sent to FB as a
reply to their request. FB transforms this content according to their rules
(javascript, css, ...) and sends it to the end user.


All this is not exactly relevant to our issue, but it shows that your app,
in the FB context, relies on data that are stored and managed remotely. And
the only data that's supposed to be stored (for a reasonably long time) by
your application, if you respect FB application developper agreement, is the
user id.

Hope it helps.
Nicolas

Re: [photon.users] Minimal user object requirements

From:
Loic d'Anterroches
Date:
2011-03-24 @ 15:03

On 2011-03-24 15:51, nico wrote:
>     > Well, an application relying on a remotely-stored user (Facebook apps
>     > for instance) will most likely store a user id, and  use it as the
>     user
>     > identifier property. Every other data provided by the remote service
>     > will be used as labels. This is mostly because these properties are
>     > managed remotely and could change over time.
> 
>     Do you have an example in "pseudo" code. I have never done this, so a
>     small example would help me understand the situation.
> 
> 
> Here is how it works :
> 
> 1- A user "installs" your application on Facebook
> It means he accesses it for the first time, and is prompted to accept to
> share some data with your application. He answers yes and is now
> registered as a user for your application.
> 
> 2- The user accesses your application
> The screens of your application are accessed by Facebook. Literally, the
> user stays on the facebook.com <http://facebook.com> domain, and FB acts
> as a proxy, forwarding the requests to the corresponding pages. These
> requests include various data (available in $_POST), and particularly
> the current user id, which is described by FB as the universal
> identifier for a User registered on FB. It might also include the user's
> friend's ids.
> 
> 3- Your app does what it has to do
> Your app does it's magic, perhaps making FB API calls to get personal
> informations about the user (name, status, events, ...) always using the
> user id. In the end your app generates the content that is sent to FB as
> a reply to their request. FB transforms this content according to their
> rules (javascript, css, ...) and sends it to the end user.
> 
> 
> All this is not exactly relevant to our issue, but it shows that your
> app, in the FB context, relies on data that are stored and managed
> remotely. And the only data that's supposed to be stored (for a
> reasonably long time) by your application, if you respect FB application
> developper agreement, is the user id.

Thanks a lot! I am totally new to this kind of stuff, I was not aware
that FB had such a level of control on what is running on their platform.

So effectively the "facebook id" does not fully match the "login"
semantic. Is the id an integer? A string? An integer to be considered as
a string (32bit limit)?

loïc

Re: [photon.users] Minimal user object requirements

From:
nico
Date:
2011-03-24 @ 15:19
>
> Thanks a lot! I am totally new to this kind of stuff, I was not aware
> that FB had such a level of control on what is running on their platform.
>
> So effectively the "facebook id" does not fully match the "login"
> semantic. Is the id an integer? A string? An integer to be considered as
> a string (32bit limit)?
>

Pre-2009 accounts are INT32, and post-2009 accounts are INT64.

Not sure how PHP handles INT64 though...which would explain why FB provides
it as a string, as stated in their documentation :
https://developers.facebook.com/docs/reference/api/user/

An example of the provided JSON : https://graph.facebook.com/nsebban

Nicolas

Re: [photon.users] Minimal user object requirements

From:
Thomas Keller
Date:
2011-03-24 @ 15:43
Am 24.03.2011 16:19, schrieb nico:
> Not sure how PHP handles INT64 though...

PHP's int's are 64bit on 64bit platforms and 32bit on 32bit platforms -
so its totally reliable. Thats why PHP has this super-useful bcmath
extension that is enabled on some setup with lots of luck.

<sarcasm off />

Thomas.

-- 
GPG-Key 0x160D1092 | tommyd3mdi@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

Re: [photon.users] Minimal user object requirements

From:
Loic d'Anterroches
Date:
2011-03-24 @ 19:04

On 2011-03-24 16:43, Thomas Keller wrote:
> Am 24.03.2011 16:19, schrieb nico:
>> Not sure how PHP handles INT64 though...
> 
> PHP's int's are 64bit on 64bit platforms and 32bit on 32bit platforms -
> so its totally reliable. Thats why PHP has this super-useful bcmath
> extension that is enabled on some setup with lots of luck.
> 
> <sarcasm off />

I must say, ok, one could have used int64 for the int on a 32bit
platform, but this would mean that all the integer operations would be
slower to emulate the 64bit operations on a 32bit system. But in
practice, who is doing large integer operations in PHP? Nobody. You only
have some issues when starting to play with files greater than 2GB with
the native PHP functions on a 32bit system. But this is a edge case.

So, at the end I am happy with this limitation because 99.99% of the
time it does not affect me and "solving" the 0.01% case would result in
a slower 99.99%.

<rant mode>

Note that I take the same approach with Photon. Yes I can add methods
isPost() isGet() isPut() on my request object, it will please people
coming from some other framework, but when you start to have such
spaghetti level of methods to please the 5%, you end-up with that:

http://symfony.com/doc/2.0/book/page_creation.html

This is a Hello World application example. They have probably been
thinking at all the edge cases they had during the last 5 years of using
Symfony 1.x and included all the best practices to address all the cases.

But you pay a very heavy price when going this way because anyway, your
CPU is limited. You can only run that many instructions per second, if
you want to go faster you need to do less.

Going back to the 4 core elements you can customize or will be able to
swap in Photon (users, sessions, auth, acl), it is very important to
have them as small as possible. Following Dieter Rams[1]: "Good design
is as little design as possible."

The simplicity of Photon brings:

- Performance.
- Fast learning curve.
- Ease of debugging.
- Ease of refactoring to improve.

Your framework in whatever language is like your backpack when you go
hiking. You have the people which are going to carry 30kg of stuff and
the one with 8kg. Effectively with 30kg you theoritically have
everything to support all the kind of weather and everything. This are
the people with money but no experience going in a "hikking superstore"
and buying everything for all cases. You have the people with experience
who say, anyway, if the weather is so terrible that my gore tex + fleece
sweat shirt will not suffice, I will not go out or I will be agile
enough to adapt. You know the ones who are doing long and wonderful
tours at the end.

The same with the development of a project, the success of Indefero 1.1
came from the developers but also me, when I said: I trust you
developers to do the right thing. We can fix later in case of problem.
When you look at Symfony (easy target I know) what you read is:

"Symfony is a PHP Framework, a Philosophy, and a Community - all working
together in harmony." What is the philosophy of a system where you have
interfaces, type hints, contracts everywhere? You not only pay the
performance price, but it also means: you developer, I do not trust you.
I will force you to follow my rules, I will enforce the rules if you
find that doing different could be better.

I am rude when I am writing this, but hey, this is my rant against the
over engineering.

</rant mode>

I will need to formalize a bit my thinking and write it done in a less
flameware kind of essay.

loïc


[1]: http://en.wikipedia.org/wiki/Dieter_Rams

Re: [photon.users] Minimal user object requirements

From:
Thomas Keller
Date:
2011-03-24 @ 22:16
Am 24.03.11 20:04, schrieb Loic d'Anterroches:
> 
> 
> On 2011-03-24 16:43, Thomas Keller wrote:
>> Am 24.03.2011 16:19, schrieb nico:
>>> Not sure how PHP handles INT64 though...
>>
>> PHP's int's are 64bit on 64bit platforms and 32bit on 32bit platforms -
>> so its totally reliable. Thats why PHP has this super-useful bcmath
>> extension that is enabled on some setup with lots of luck.
>>
>> <sarcasm off />
> 
> I must say, ok, one could have used int64 for the int on a 32bit
> platform, but this would mean that all the integer operations would be
> slower to emulate the 64bit operations on a 32bit system. But in
> practice, who is doing large integer operations in PHP? Nobody. You only
> have some issues when starting to play with files greater than 2GB with
> the native PHP functions on a 32bit system. But this is a edge case.

It would have been helpful to have introduced a specific 64bit integer
type. One very bad example where shit hits the fan is PHP's SOAP (which
is braindead for various reasons). Here's the catch: If a SOAP message
comes with a field that contains a 64bit integer number it does not
leave it by default as string, but converts it into a 52bit floating
point number. Well, better than nothing you'd say, but to get the "real"
value you have to develop custom XML (de)serializers that have to be
attached to the SOAP client. Ugly, no actually, super ugly.

[super-snip]
> So, at the end I am happy with this limitation because 99.99% o
> "Symfony is a PHP Framework, a Philosophy, and a Community - all working
> together in harmony." What is the philosophy of a system where you have
> interfaces, type hints, contracts everywhere? You not only pay the
> performance price, but it also means: you developer, I do not trust you.
> I will force you to follow my rules, I will enforce the rules if you
> find that doing different could be better.
> 
> I am rude when I am writing this, but hey, this is my rant against the
> over engineering.

It is true that the Symfony guys always hunt for perfection - I
personally observed this a lot with a Symfony CMS extension I had to use
for a project, Sympal, whose internal design changed over and over again
from version to version just to make it a little more "uncoupled",
almost to a point where it was unusable. (Now its more or less dead and
the developer teamed up with others working on an even bigger potemkin
village, named "Symfony 2 Content Management Framework".)

Anyways, I have a different attitude towards clean design and I don't
see the usage of interfaces and type hints as overengineering, but the
freedom to really extend and test stuff easily. For what its worth, I'm
currently writing a test case for IDF_Scm_Monotone_ZipRender and I'm
using type hints and interfaces exactly for this, testing, because they
enable me to write mocked data drivers really easily.

Enough gossip from me now :)

Thomas.

-- 
GPG-Key 0x160D1092 | tommyd3mdi@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

Re: [photon.users] Minimal user object requirements

From:
Loic d'Anterroches
Date:
2011-03-25 @ 08:36

On 2011-03-24 23:16, Thomas Keller wrote:
> Am 24.03.11 20:04, schrieb Loic d'Anterroches:
>> On 2011-03-24 16:43, Thomas Keller wrote:
>>> Am 24.03.2011 16:19, schrieb nico:
>>>> Not sure how PHP handles INT64 though...
>>>
>>> PHP's int's are 64bit on 64bit platforms and 32bit on 32bit platforms -
>>> so its totally reliable. Thats why PHP has this super-useful bcmath
>>> extension that is enabled on some setup with lots of luck.
>>>
>>> <sarcasm off />
>>
>> I must say, ok, one could have used int64 for the int on a 32bit
>> platform, but this would mean that all the integer operations would be
>> slower to emulate the 64bit operations on a 32bit system. But in
>> practice, who is doing large integer operations in PHP? Nobody. You only
>> have some issues when starting to play with files greater than 2GB with
>> the native PHP functions on a 32bit system. But this is a edge case.
> 
> It would have been helpful to have introduced a specific 64bit integer
> type. One very bad example where shit hits the fan is PHP's SOAP (which
> is braindead for various reasons). Here's the catch: If a SOAP message
> comes with a field that contains a 64bit integer number it does not
> leave it by default as string, but converts it into a 52bit floating
> point number. Well, better than nothing you'd say, but to get the "real"
> value you have to develop custom XML (de)serializers that have to be
> attached to the SOAP client. Ugly, no actually, super ugly.

SOAP, maybe the problem is more SOAP than PHP in this case.

> [super-snip]
>> So, at the end I am happy with this limitation because 99.99% o
>> "Symfony is a PHP Framework, a Philosophy, and a Community - all working
>> together in harmony." What is the philosophy of a system where you have
>> interfaces, type hints, contracts everywhere? You not only pay the
>> performance price, but it also means: you developer, I do not trust you.
>> I will force you to follow my rules, I will enforce the rules if you
>> find that doing different could be better.
>>
>> I am rude when I am writing this, but hey, this is my rant against the
>> over engineering.
> 
> It is true that the Symfony guys always hunt for perfection - I
> personally observed this a lot with a Symfony CMS extension I had to use
> for a project, Sympal, whose internal design changed over and over again
> from version to version just to make it a little more "uncoupled",
> almost to a point where it was unusable. (Now its more or less dead and
> the developer teamed up with others working on an even bigger potemkin
> village, named "Symfony 2 Content Management Framework".)
> 
> Anyways, I have a different attitude towards clean design and I don't
> see the usage of interfaces and type hints as overengineering, but the
> freedom to really extend and test stuff easily. For what its worth, I'm
> currently writing a test case for IDF_Scm_Monotone_ZipRender and I'm
> using type hints and interfaces exactly for this, testing, because they
> enable me to write mocked data drivers really easily.

This is interesting me. This is the first time I read about a useful use
of type hints and interfaces. Looking forward to read your code and
learn something.

loïc