Hi,
PHP has to be unique, using the double colon notation would be too
cliche, but if we're not respecting conventions, why not go with
something more exotic? I've always liked the o with the slash trough
it. The e with the horizontal colon is also pretty nice. The n with
the tilde over it, it so strongly says _n_amespace.
When I read this message first thing I did was check the date, but
deep down I knew it wasn't April yet.
One of the top reasons why I hate using windows consoles is the
dreaded "" character.
Each and every keyboard model I have has this key in a different
place, sometimes one hard to reach. Every time I'm in doing a cd in
windows I press 2-3 other keys while going for the backslash.
That whole rating table over on the PHP wiki is just ridiculous.
- type-ability: come on. If anything, it should get -1 there
- typo-vulnerability: pretty big, but I think most problems will be
escaping rather than typos anyway - number of chars: any sane person will agree that you can write
"::" a lot faster than "" - editor integration: not really, many editors will have trouble, including vim
I eagerly await namespaces in PHP, but guys, if you don't have a good
idea, I think copying is better than implementing a bad one.
\Tudor
Tudor Prodan wrote:
PHP has to be unique, using the double colon notation would be too
cliche, but if we're not respecting conventions, why not go with
something more exotic? I've always liked the o with the slash trough
it. The e with the horizontal colon is also pretty nice. The n with
the tilde over it, it so strongly says _n_amespace.When I read this message first thing I did was check the date, but
deep down I knew it wasn't April yet.One of the top reasons why I hate using windows consoles is the
dreaded "" character.Each and every keyboard model I have has this key in a different
place, sometimes one hard to reach. Every time I'm in doing a cd in
windows I press 2-3 other keys while going for the backslash.That whole rating table over on the PHP wiki is just ridiculous.
- type-ability: come on. If anything, it should get -1 there
- typo-vulnerability: pretty big, but I think most problems will be
escaping rather than typos anyway- number of chars: any sane person will agree that you can write
"::" a lot faster than ""- editor integration: not really, many editors will have trouble, including vim
I eagerly await namespaces in PHP, but guys, if you don't have a good
idea, I think copying is better than implementing a bad one.
Tudor - There is little point reiterating half of the facts. There are very
good reasons why - for PHP - a simple solution was not working. MANY people
were coming up with problems as to why the currently implemented 'solution'
was only going to create a black hole at some point, and what ever was doing
to be done was going to cause problems somewhere.
The backslash is not ideal, but I think we all need to get behind it rather
than complaining. The only other real alternative today is to shelve
namespaces altogether for the next release rather than putting something in
that is simply not practical to extend later?
Given the polarised views a total solution that everybody could agree with was
just not happening!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Well, given how much PHP has copied from C (and I mean that in a good
way), why not copy the sane, less-controversial namespace separator
and behavior that we all know and love?
\Tudor
Tudor Prodan wrote:
PHP has to be unique, using the double colon notation would be too
cliche, but if we're not respecting conventions, why not go with
something more exotic? I've always liked the o with the slash trough
it. The e with the horizontal colon is also pretty nice. The n with
the tilde over it, it so strongly says _n_amespace.When I read this message first thing I did was check the date, but
deep down I knew it wasn't April yet.One of the top reasons why I hate using windows consoles is the
dreaded "" character.Each and every keyboard model I have has this key in a different
place, sometimes one hard to reach. Every time I'm in doing a cd in
windows I press 2-3 other keys while going for the backslash.That whole rating table over on the PHP wiki is just ridiculous.
- type-ability: come on. If anything, it should get -1 there
- typo-vulnerability: pretty big, but I think most problems will be
escaping rather than typos anyway- number of chars: any sane person will agree that you can write
"::" a lot faster than ""- editor integration: not really, many editors will have trouble,
including vimI eagerly await namespaces in PHP, but guys, if you don't have a good
idea, I think copying is better than implementing a bad one.Tudor - There is little point reiterating half of the facts. There are very
good reasons why - for PHP - a simple solution was not working. MANY people
were coming up with problems as to why the currently implemented 'solution'
was only going to create a black hole at some point, and what ever was doing
to be done was going to cause problems somewhere.The backslash is not ideal, but I think we all need to get behind it rather
than complaining. The only other real alternative today is to shelve
namespaces altogether for the next release rather than putting something in
that is simply not practical to extend later?Given the polarised views a total solution that everybody could agree with
was just not happening!--
Lester Caine - G8HFLContact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Well, given how much PHP has copied from C (and I mean that in a good
way), why not copy the sane, less-controversial namespace separator
and behavior that we all know and love?
because C is static, and PHP is dynamic
it was already discussed — browse archives, please
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
I want to express my happiness of finally having an agreement/solution for
the namespaces.
I have something like 70 000 LOC with namespaces (and a lot of static
calls/class consts) so it will take some time to convert it to \ but I'm
still very happy to have a solution. Like Karsten Dambekalns said in one of
the threads it is more important to have ns support than the precise way it
will be implemented/separator used, no matter that we have code written
already - we will modify it.
As a personal opinion - the backslash is fine for me because:
- it is only one character
- readable enough (something\another\thing)
- no BC (like the proposed#hash#sign)
- it will be somewhat familiar for the windows users (I'm not, but still is
a +)
I really hope that after testing the patch there will be no issues and this
solution will get into the final version (and will put the end of the ns
discussion). Big thanks to the people involved!
--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com
Lester Caine wrote:
The backslash is not ideal, but I think we all need to get behind it
rather than complaining. The only other real alternative today is to
shelve namespaces altogether for the next release rather than putting
something in that is simply not practical to extend later?
I'd prefer to see it shelved for another release with the aim of fixing
whatever technical barriers made the syntax unworkable in the first
place. I'm sure you'd have plenty of volunteers.
My personal concern is that once this goes public, we (the end users)
are stuck with that decision for the forseeable future.
I think there's obviously enough unhappy campers here that this option
should be at least considered. Not that I'm holding my breath or anything.
Everybody seems to be getting awfully emotional about this ...
Cheers,
T
This was argued for months, there was tons of emails to read and backslash
is best for most people. PHP is dynamic language - that makes some major
restrictions, so you just can't apply something that is already in use
easily. That's why :: was rejected in first place. That's why . was
rejected, other separators had other issues. Backslash is easy to see, easy
to type (most layouts have it without Shift or something else) and clearly
says - I'm a namespace!
So anyway - in any language you will find something that you would't like.
You just live with that or chouse another language. That's all.
2008/10/27 Thomas Lee tom@vector-seven.com
Lester Caine wrote:
The backslash is not ideal, but I think we all need to get behind it
rather than complaining. The only other real alternative today is to shelve
namespaces altogether for the next release rather than putting something in
that is simply not practical to extend later?I'd prefer to see it shelved for another release with the aim of fixing
whatever technical barriers made the syntax unworkable in the first place.
I'm sure you'd have plenty of volunteers.My personal concern is that once this goes public, we (the end users) are
stuck with that decision for the forseeable future.I think there's obviously enough unhappy campers here that this option
should be at least considered. Not that I'm holding my breath or anything.Everybody seems to be getting awfully emotional about this ...
Cheers,
T
So does that mean the new NS operator is actually \ and not \ ?
No developer is going to be relying on single 's -- too likely to become an
error in maintenence, and too inconsistent (see strings discussion).
Jevon
On Tue, Oct 28, 2008 at 12:11 AM, Arvids Godjuks
arvids.godjuks@gmail.comwrote:
This was argued for months, there was tons of emails to read and backslash
is best for most people. PHP is dynamic language - that makes some major
restrictions, so you just can't apply something that is already in use
easily. That's why :: was rejected in first place. That's why . was
rejected, other separators had other issues. Backslash is easy to see, easy
to type (most layouts have it without Shift or something else) and clearly
says - I'm a namespace!
So anyway - in any language you will find something that you would't like.
You just live with that or chouse another language. That's all.2008/10/27 Thomas Lee tom@vector-seven.com
Lester Caine wrote:
The backslash is not ideal, but I think we all need to get behind it
rather than complaining. The only other real alternative today is to
shelve
namespaces altogether for the next release rather than putting something
in
that is simply not practical to extend later?I'd prefer to see it shelved for another release with the aim of fixing
whatever technical barriers made the syntax unworkable in the first
place.
I'm sure you'd have plenty of volunteers.My personal concern is that once this goes public, we (the end users) are
stuck with that decision for the forseeable future.I think there's obviously enough unhappy campers here that this option
should be at least considered. Not that I'm holding my breath or
anything.Everybody seems to be getting awfully emotional about this ...
Cheers,
T
I disagree that PHP being a dynamic language justifies the introduction
of deeply unpopular syntax. I mean, PHP developers are your end users.
Bad past design decisions aside, you don't want to alienate your users.
And yes, this has probably been argued in the past. Unfortunately, it
looks like you have people's attention now.
You're also right in that we can choose another language. I just wonder
why you'd be so eager to encourage it.
Anyway, my point is that there may be other options. Such as putting off
a long-sought feature until it can be implemented properly.
Cheers,
T
Arvids Godjuks wrote:
This was argued for months, there was tons of emails to read and backslash
is best for most people. PHP is dynamic language - that makes some major
restrictions, so you just can't apply something that is already in use
easily. That's why :: was rejected in first place. That's why . was
rejected, other separators had other issues. Backslash is easy to see, easy
to type (most layouts have it without Shift or something else) and clearly
says - I'm a namespace!
So anyway - in any language you will find something that you would't like.
You just live with that or chouse another language. That's all.2008/10/27 Thomas Lee tom@vector-seven.com
Lester Caine wrote:
The backslash is not ideal, but I think we all need to get behind it
rather than complaining. The only other real alternative today is to shelve
namespaces altogether for the next release rather than putting something in
that is simply not practical to extend later?I'd prefer to see it shelved for another release with the aim of fixing
whatever technical barriers made the syntax unworkable in the first place.
I'm sure you'd have plenty of volunteers.My personal concern is that once this goes public, we (the end users) are
stuck with that decision for the forseeable future.I think there's obviously enough unhappy campers here that this option
should be at least considered. Not that I'm holding my breath or anything.Everybody seems to be getting awfully emotional about this ...
Cheers,
T
I disagree that PHP being a dynamic language justifies the
introduction of deeply unpopular syntax. I mean, PHP developers are
your end users. Bad past design decisions aside, you don't want to
alienate your users.And yes, this has probably been argued in the past. Unfortunately, it
looks like you have people's attention now.You're also right in that we can choose another language. I just
wonder why you'd be so eager to encourage it.Anyway, my point is that there may be other options. Such as putting
off a long-sought feature until it can be implemented properly.
How would delyaing it help? We'd need to have the same discussion
anyway. If we could have made :: work, we would have. Greg (and others)
spend countless hours trying out different concepts, with different pros
and cons -- you can find those on the wiki as RFCs. The only way how
all issues could be solved was by picking a different namespace
separator. There would have been anything that could have changed this
without creating any sort of BC issues. From the possible namespace
separators, \ was the best one as we could see. That's how it is, that's
how it will be. Now get some coffee and quit bitching.
Derick
--
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
How would delyaing it help?
I agree, delaying will not help (and namespaces are the most expected
feature in PHP 5.3).
If we could have made :: work, we would have. Greg (and others)
spend countless hours trying out different concepts, with different pros
and cons -- you can find those on the wiki as RFCs.
But what is the purpose of namespaces? To give developers their own
separated space. And it is their responsibility to not use ambiguous
names. PHP has not problem with class Foo::Bar and namespace Foo::Bar,
but coding standards usually prohibits it.
Developers are not stupid. I think there is no reason to PHP trying be
smarter than them.
(I know, this is kind of philosopher argument, but the same thinking
works in C++ well).
The only way how
all issues could be solved was by picking a different namespace
separator. There would have been anything that could have changed this
without creating any sort of BC issues. From the possible namespace
separators, \ was the best one as we could see. That's how it is, that's
I will be glad for each separator, but :: is the best one :-))
David Grudl
David Grudl wrote:
But what is the purpose of namespaces? To give developers their own
separated space. And it is their responsibility to not use ambiguous
names. PHP has not problem with class Foo::Bar and namespace Foo::Bar,
but coding standards usually prohibits it.
+1 to that.
Cheers,
T
Hi Thomas,
Anyway, my point is that there may be other options. Such as putting off a
long-sought feature until it can be implemented properly.
OK, since you obviously didn't do any background reading before posting to
this list, let me direct you to the history behind this decision once again:
http://wiki.php.net/rfc/namespaceseparator. Let me also point out that this
only covers the last few weeks; the namespace discussions on this very list,
in-depth and otherwise, date back some 5 years.
If you read everything linked from that RFC, you will discover that there
are two ways to implement namespace support in PHP 'properly'.
- We can offer support for classes only and throw a fatal error when a
function is encountered in namespaced code - We can use a namespace separator other than ::
There is of course always option 3...
- We can drop the whole idea of namespace support because whatever is done
will appear 'wrong' to /. readers
Every other option leads to ambiguity in namespace syntax. That's not
because we need more time to think things over so it can be 'implemented
properly', it's just straight fact.
- Steph
Steph Fox wrote:
Hi Thomas,
Anyway, my point is that there may be other options. Such as putting
off a long-sought feature until it can be implemented properly.OK, since you obviously didn't do any background reading before
posting to this list, let me direct you to the history behind this
decision once again: http://wiki.php.net/rfc/namespaceseparator. Let
me also point out that this only covers the last few weeks; the
namespace discussions on this very list, in-depth and otherwise, date
back some 5 years.
Actually I've been following namespaces for a fair while, but the issue
of :: being a problem wasn't really raised until a few weeks ago. So
while I'm aware of namespaces being under discussion for a fair while,
yesterday was the first I'd heard about a decision being made for the
backslash being used as a namespace separator. Sounds like I'm not the
only one.
Hope it all works out, either way.
Cheers,
T
Hi Thomas,
Actually I've been following namespaces for a fair while, but the issue of
:: being a problem wasn't really raised until a few weeks ago. So while
I'm aware of namespaces being under discussion for a fair while, yesterday
was the first I'd heard about a decision being made for the backslash
being used as a namespace separator. Sounds like I'm not the only one.
OK, sorry if that seemed unfair. I should've aimed it at certain others
really ;)
You're correct, the :: issues were only fully understood when Greg took the
time to investigate the options thoroughly. So you didn't miss a lot.
Namespace separator discussions were long-winded and involved every Tom
Dick and Harry turning up on internals@ with increasingly bizarre ideas,
every time the subject arose over the last few years. That was when the real
discussion of separator options took place.
Lukas simply summarized the issues around the available options in his table
during the irc discussion last Saturday, but the fact is he couldn't have
really known the criteria - or the available symbols - without having those
lengthy public discussions behind him. We couldn't have known his criteria
and symbol set were correct without that history either; we'd have been
stuck on 'why not :' forever.
Hope it all works out, either way.
As do we all :)
- Steph
Actually I've been following namespaces for a fair while, but the
issue of :: being a problem wasn't really raised until a few weeks
ago.
I realize this isn't a terribly constructive comment as it doesn't
solve any problems, but I hope it's constructive in the way that it
actually causes people to do as Derick said and go get a coffee
instead of whining about syntax... AGAIN.
The issue of :: being a problem (causes ambiguity) was part of the
ORIGINAL namespace discussion that took place 3 years ago. Some of us
have been dealing with people complaining about this for 3 years (I
blogged about ::: and \ in 2005), and I'm very happy we've finally
come to a resolution. If the core developers chose another operator,
then DIFFERENT people would be whining, so it's lose-lose.
Now, sit back, relax, trust that the developers who chose this
actually have half a clue, and stop crying wolf—all of you.
S
Hi!
If you read everything linked from that RFC, you will discover that
there are two ways to implement namespace support in PHP 'properly'.
- We can offer support for classes only and throw a fatal error when a
function is encountered in namespaced code- We can use a namespace separator other than ::
These aren't the only ways.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
These aren't the only ways.
OK.
- Claim that there is no real problem in addressing ambiguous situations.
- Steph
Hi!
OK.
- Claim that there is no real problem in addressing ambiguous situations.
This is not what I meant, but there's obviously neither use nor interest
in further discussing this topic as decision was already taken. I only
wish people would not start rewriting history as other opinions or
options didn't even exist so soon. I'm fine with making the choice, what
I'm not fine with is presenting the thing as there was never any other
options at all. We had plenty of options, maybe too many, we tried to
choose the best, time will tell if we succeeded. Memory hole is not
necessary for that.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
This is not what I meant, but there's obviously neither use nor interest
in further discussing this topic as decision was already taken. I only
wish people would not start rewriting history as other opinions or options
didn't even exist so soon. I'm fine with making the choice, what I'm not
fine with is presenting the thing as there was never any other options at
all. We had plenty of options, maybe too many, we tried to choose the
best, time will tell if we succeeded. Memory hole is not necessary for
that.
My apologies. I was talking about what we were left with by the time we
reached the point of needing a meeting. There were of course several
attempts (recent and not so recent) to retain :: because this is what
everyone would have preferred to do. I certainly didn't intend to leave
the impression that this hadn't been investigated fully, or that there
weren't several proposals of ways to get around the known problems.
- Steph
I apologise for being silent on this issue to date (been busy), but I feel that
I must comment even if the decision is now 'final'.
I disagree that PHP being a dynamic language justifies the introduction
of deeply unpopular syntax. I mean, PHP developers are your end users.
Bad past design decisions aside, you don't want to alienate your users.And yes, this has probably been argued in the past. Unfortunately, it
looks like you have people's attention now.
Like mine.
The backslash character will cause much WTF to even experienced people.
\ is just too magic in all sorts of ways.
Trying to interpolate into a string is one that will cause huge problems.
How about :.: -- OK it is a bit longer, but is clear, it doesn't suffer from the
problem that ::: has (ie 2 or 3 ':'s leading to errors). I believe that '.' and ':'
are available on most national language keyboards.
The real problem is that we have run out of extra symbols.
If you don't like the suggestion above, there are many others in that family, eg:
:=: :+: :_: :-: :@: <:> <@>
The other thing that has always puzzled me about namespaces is that they do NOT
include varaibles - one of the things that I would most want to wrap up in a namespace.
I accept that variables in a namespace would not be in $GLOBALS, but that is no great
loss ... if people really want it we could always define: $_NAMESPACEVARS['foo:.:bar']
as an array of variables in namespace foo:.:bar.
Maybe $_NAMESPACES would be an array of all namespaces that are defined.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
I agree with Thomas Lee, if the backslash ever gets released, it's
there forever.
Who uses functions and variables in a namespace anyway? very few
Will that small part of the users even use namespaces? probably not
So, why not ban these from namespaces and save all the trouble?
If however a user will want to do this the bad way, he can always use statics.
This way all the trouble is dumped on that small part of users that,
again, will most likely not even use namespaces to begin with.
\Tudor
I apologise for being silent on this issue to date (been busy), but I feel that
I must comment even if the decision is now 'final'.I disagree that PHP being a dynamic language justifies the introduction
of deeply unpopular syntax. I mean, PHP developers are your end users.
Bad past design decisions aside, you don't want to alienate your users.And yes, this has probably been argued in the past. Unfortunately, it
looks like you have people's attention now.Like mine.
The backslash character will cause much WTF to even experienced people.
\ is just too magic in all sorts of ways.Trying to interpolate into a string is one that will cause huge problems.
How about :.: -- OK it is a bit longer, but is clear, it doesn't suffer from the
problem that ::: has (ie 2 or 3 ':'s leading to errors). I believe that '.' and ':'
are available on most national language keyboards.The real problem is that we have run out of extra symbols.
If you don't like the suggestion above, there are many others in that family, eg:
:=: :+: :_: :-: :@: <:> <@>The other thing that has always puzzled me about namespaces is that they do NOT
include varaibles - one of the things that I would most want to wrap up in a namespace.
I accept that variables in a namespace would not be in $GLOBALS, but that is no great
loss ... if people really want it we could always define: $_NAMESPACEVARS['foo:.:bar']
as an array of variables in namespace foo:.:bar.
Maybe $_NAMESPACES would be an array of all namespaces that are defined.--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
- One user of namespaced constants & functions here... I dont like to use
objects for everything. I have very few constants & functions but I would
like them to remain constants & functions instead of converting them to
static classes or object methods. - One reason against dropping ns for functions & constants is that if you
drop them how you can namespace legacy (or to avoid that word, not OOP)
code? This way many libraries can not be namespaced and if you have a name
collision you will not be able to solve it using namespaces. - I prefer using\name\spaces instead of prefixing_my_classes. Here is why -
I want to organize my files in a hierarchical way in the file structure. A
possible solution withtout namespace using prefixes couldbe
level1_level2_classname (spliting the name by _). But if I want it to be
class_name? Then I have an confusion. And I personaly dislike camelCase and
level1_level2_className does not works for me.
Because of this I prefer to have namespaces instead of class prefixes. Then
I can do name\space\class_name. - When you have namespace you can short_the_long_class_name used multiple
times in your code importing the namespace and then using the 'shortcut'.
I put the last two just to explain why I prefer to have namespace with
whatever by separator instead of dropping them.
On Mon, Oct 27, 2008 at 2:29 PM, Tudor Prodan tudor.prodan@gmail.comwrote:
I agree with Thomas Lee, if the backslash ever gets released, it's
there forever.Who uses functions and variables in a namespace anyway? very few
Will that small part of the users even use namespaces? probably notSo, why not ban these from namespaces and save all the trouble?
If however a user will want to do this the bad way, he can always use
statics.
This way all the trouble is dumped on that small part of users that,
again, will most likely not even use namespaces to begin with.\Tudor
I apologise for being silent on this issue to date (been busy), but I
feel that
I must comment even if the decision is now 'final'.I disagree that PHP being a dynamic language justifies the introduction
of deeply unpopular syntax. I mean, PHP developers are your end users.
Bad past design decisions aside, you don't want to alienate your users.And yes, this has probably been argued in the past. Unfortunately, it
looks like you have people's attention now.Like mine.
The backslash character will cause much WTF to even experienced people.
\ is just too magic in all sorts of ways.Trying to interpolate into a string is one that will cause huge problems.
How about :.: -- OK it is a bit longer, but is clear, it doesn't suffer
from the
problem that ::: has (ie 2 or 3 ':'s leading to errors). I believe that
'.' and ':'
are available on most national language keyboards.The real problem is that we have run out of extra symbols.
If you don't like the suggestion above, there are many others in that
family, eg::=: :+: :_: :-: :@: <:> <@>The other thing that has always puzzled me about namespaces is that they
do NOT
include varaibles - one of the things that I would most want to wrap up
in a namespace.
I accept that variables in a namespace would not be in $GLOBALS, but that
is no great
loss ... if people really want it we could always define:
$_NAMESPACEVARS['foo:.:bar']
as an array of variables in namespace foo:.:bar.
Maybe $_NAMESPACES would be an array of all namespaces that are defined.--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer,
IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h>--
--
--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com
Vesselin Kenashkov wrote:
- One user of namespaced constants & functions here... I dont like to use
objects for everything. I have very few constants & functions but I would
like them to remain constants & functions instead of converting them to
static classes or object methods.- One reason against dropping ns for functions & constants is that if you
drop them how you can namespace legacy (or to avoid that word, not OOP)
code? This way many libraries can not be namespaced and if you have a name
collision you will not be able to solve it using namespaces.- I prefer using\name\spaces instead of prefixing_my_classes. Here is why -
I want to organize my files in a hierarchical way in the file structure. A
possible solution withtout namespace using prefixes couldbe
level1_level2_classname (spliting the name by _). But if I want it to be
class_name? Then I have an confusion. And I personaly dislike camelCase and
level1_level2_className does not works for me.
Because of this I prefer to have namespaces instead of class prefixes. Then
I can do name\space\class_name.- When you have namespace you can short_the_long_class_name used multiple
times in your code importing the namespace and then using the 'shortcut'.I put the last two just to explain why I prefer to have namespace with
whatever by separator instead of dropping them.
I'm with you on that Vesselin. Will I use namespace - probably not, but I can
see straight away blocks of code in projects I'm involved with that require
functions at least in the namespace. SO they should be re-written? Probably,
but one of the tidiest ways of handling even that is to wrap the legacy code
in it's own namespace. If functions and constants were dropped simply to push
an incomplete solution through, then it would cause a lot more trouble than
the current flack. The result is not 'ideal' but it is perfectly functional
and from what I've seen so far WILL work with legacy code.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php