Namespace issues - Externals

17 years ago by Marcel Esser — view source — reply

unread

Using ::: as a namespace seperator would be great.

Marcel Esser, Technical Lead
Croscon, LLC
http://www.croscon.com

17 years ago by William A. Rowe — view source — reply

unread

Marcel Esser wrote:

Using ::: as a namespace seperator would be great.

A general rule of telephony dialing and other data input, three of
the same character will too often be entered or recognized as two
or four characters due to user or mechanical error. That's why
when you see mnemonic phone numbers they rarely repeat three
digits in the middle (three 0's at the end for example aren't
subject to the excess fourth repetition problem).

17 years ago by Marcus Boerger — view source — reply

unread

Hello William,

Friday, October 17, 2008, 7:57:53 PM, you wrote:

Marcel Esser wrote:

Using ::: as a namespace seperator would be great.

A general rule of telephony dialing and other data input, three of
the same character will too often be entered or recognized as two
or four characters due to user or mechanical error. That's why
when you see mnemonic phone numbers they rarely repeat three
digits in the middle (three 0's at the end for example aren't
subject to the excess fourth repetition problem).

This is the major flaw with that solution. Personally I just looked at
working code that had (:::) and () which is the second option I also
mentioned already long ago. And (:::) can be read very easy. The visual
difference to (::) is big enough. However it is too easy to either type
two or four. Thus the backslash (the only other conflict free) character
is probably the better option - even though no one has done something
like that. Btw, it pretty much suggests thatyou use the same structure
for your directories and files. Which you'd do inside __autoload() most
likely anyway.

Best regards,
Marcus

17 years ago by Marcus Boerger — view source — reply

unread

Hello all,

Greg was so kind to give me part of his awesome upcoming Pyrus code. He
actually has it running with both ':::' and '' as namespace separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice of
having a look at actual working code:

http://php.net/~helly/triplecolon.html
http://php.net/~helly/triplecolon-colored.html
http://php.net/~helly/backslash-colored.html
http://php.net/~helly/backslash.html

marcus

Saturday, October 18, 2008, 11:03:50 PM, you wrote:

Hello William,

Friday, October 17, 2008, 7:57:53 PM, you wrote:

Marcel Esser wrote:

Using ::: as a namespace seperator would be great.

A general rule of telephony dialing and other data input, three of
the same character will too often be entered or recognized as two
or four characters due to user or mechanical error. That's why
when you see mnemonic phone numbers they rarely repeat three
digits in the middle (three 0's at the end for example aren't
subject to the excess fourth repetition problem).

This is the major flaw with that solution. Personally I just looked at
working code that had (:::) and () which is the second option I also
mentioned already long ago. And (:::) can be read very easy. The visual
difference to (::) is big enough. However it is too easy to either type
two or four. Thus the backslash (the only other conflict free) character
is probably the better option - even though no one has done something
like that. Btw, it pretty much suggests thatyou use the same structure
for your directories and files. Which you'd do inside __autoload() most
likely anyway.

Best regards,
Marcus

Best regards,
Marcus

17 years ago by Nathan Rixham — view source — reply

unread

Marcus Boerger wrote:

Hello all,

Greg was so kind to give me part of his awesome upcoming Pyrus code. He
actually has it running with both ':::' and '' as namespace separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice of
having a look at actual working code:

http://php.net/~helly/triplecolon.html
http://php.net/~helly/triplecolon-colored.html
http://php.net/~helly/backslash-colored.html
http://php.net/~helly/backslash.html

marcus

Thanks massively! Those code samples make it vastly clear just how many
times we'll all be calling functions in the default namespace - and I
for one don't fancy typing ::: for every function or normal PHP class I
ever use! + \strpos() etc. just looks and types natural to me.

I realise we wouldn't /have/ to type \ or ::: every time we call a
'normal' function, but I for one would prefer to by way of good
practise, and those extra chars make a huge difference as far as I'm
concerned.

I do not want to spend the rest of my life typing ::: in front of every
function.

note: it type's natural as the \ is right beside zxcv on my keyboard,
which I'm ctrl+tapping all the time, so comes natural to my pinky!

This is a no-brainer AFAIK.

Thanks again (really),

Nathan

17 years ago by Nathan Rixham — view source — reply

unread

Marcus Boerger wrote:

Hello all,

Greg was so kind to give me part of his awesome upcoming Pyrus code. He
actually has it running with both ':::' and '' as namespace separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice of
having a look at actual working code:

http://php.net/~helly/triplecolon.html
http://php.net/~helly/triplecolon-colored.html
http://php.net/~helly/backslash-colored.html
http://php.net/~helly/backslash.html

marcus

shift+;(x3) vs \

17 years ago by Catalin Zamfir Alexandru | KIT Software CAZ — view source — reply

unread

Quicker shift + ; x 3 than finding that freakin backslash on my HP 530 notebook.

-----Original Message-----
From: Nathan Rixham [mailto:nrixham@gmail.com]
Sent: Sunday, October 19, 2008 2:52 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Namespace issues

Marcus Boerger wrote:

Hello all,

Greg was so kind to give me part of his awesome upcoming Pyrus code.
He
actually has it running with both ':::' and '' as namespace
separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice
of
having a look at actual working code:

http://php.net/~helly/triplecolon.html
http://php.net/~helly/triplecolon-colored.html
http://php.net/~helly/backslash-colored.html
http://php.net/~helly/backslash.html

marcus

shift+;(x3) vs \

17 years ago by Steph Fox — view source — reply

unread

Greg was so kind to give me part of his awesome upcoming Pyrus code. He
actually has it running with both ':::' and '' as namespace separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice of
having a look at actual working code:

http://php.net/~helly/triplecolon.html
http://php.net/~helly/triplecolon-colored.html
http://php.net/~helly/backslash-colored.html
http://php.net/~helly/backslash.html

I did say off-list that Nathan would be an immediate fan...
(Nathan actually proposed this off-list during the survey, not knowing that
the idea had been rejected 4 years or so back.)

Revisiting this.. isn't a crime. It's the one ns separator we have available
in PHP that won't mess up for people with bad eyesight, for one. Among
developers, that's quite a big deal.

The big question is whether we need a namespace separator at all. As far as
I'm aware, this is still under investigation (and this time it's for real).

Steph

marcus

shift+;(x3) vs \

17 years ago by Lester Caine — view source — reply

unread

Nathan Rixham wrote:

Greg was so kind to give me part of his awesome upcoming Pyrus code. He
actually has it running with both ':::' and '' as namespace separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice of
having a look at actual working code:

shift+;(x3) vs \

And there are no problems with those on foreign keyboards?
I recall seeing a number of 'complaints' about some of the separator
characters that are difficult to access on foreign language keyboards. Has
anybody tabulated that so that the extent of that problem is understood?

Just an aside, and while I might put changing the separator used above adding
'use namespace', from a documentation and review of code where multiple files
are involved, going with both ( keeping finger of shift key which it goes to
automatically ;) ) makes perfect sense to me.

But do I still understand that there is an alternative method that was not
part of this last round of voting? And needs to be reviewed in light of the
current 'consensus' ?
( putting quotes around a word is automatic to me as well - just means that
the word may not be entirely appropriate but gives the right idea )

--
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

17 years ago by David Coallier — view source — reply

unread

shift+;(x3) vs \

Ok I'll try to make a very neutral comment. For the moment most are
still using an english keyboard (no matter which english in this case
and I'd actually be interested in knowing numbers for a fact if
anyone's got something) and ergonomically speaking, ::: is much easier
to type than \ for those who actually learned to type with the adsf
jkl; keyboard. When you learn typing you usually learn to type using
the left-hand side shift key for "most" of the letters/words, for
instance typing : doesn't require a movement of the right hand since
your pinky is already on the ; key whereas the \ key requires a
"not-so-used" movement of the hand.

Anyways, I was just saying that without considering the question
because I absolutely don't feel like redicussing this over and over.
We have had a massive list fight over 3-4 years ago about it and I'm
not getting into this one.

--
Slan,
David

17 years ago by Marcus Boerger — view source — reply

unread

Hello David,

Sunday, October 19, 2008, 1:02:21 PM, you wrote:

shift+;(x3) vs \

Ok I'll try to make a very neutral comment. For the moment most are
still using an english keyboard (no matter which english in this case
and I'd actually be interested in knowing numbers for a fact if
anyone's got something) and ergonomically speaking, ::: is much easier
to type than \ for those who actually learned to type with the adsf
jkl; keyboard. When you learn typing you usually learn to type using
the left-hand side shift key for "most" of the letters/words, for
instance typing : doesn't require a movement of the right hand since
your pinky is already on the ; key whereas the \ key requires a
"not-so-used" movement of the hand.

Anyways, I was just saying that without considering the question
because I absolutely don't feel like redicussing this over and over.
We have had a massive list fight over 3-4 years ago about it and I'm
not getting into this one.

All good points :-)

So for typing it sounds to me like both would work as a compromise well
enough. Also on a german keyboard layout a backslash is in the same
category than the ':'. Personally I think however that I would to often
confuse myself with typing '::' vs ':::'. Often enough I find myself typing
the wrong char, typing delete as many times as necessary to go back to the
wrong char and then typing correct again. And in those case I mostly do not
look at the screen. I look at the keyboard to ensure I type what I wanted,
fixing my hand position, no longer seeing whether that is what I needed to
type. And this works for '::' vs '' becasue they are completely different
but I think it does not work for '::' vs ':::', simply becasue that is not
a different enough and probably I know what to type always but confusing
myself with hitting the key the right amount of times.

The other parts are:
a) do we need one - I think so - because it means we solve any issue once
and forever
b) what reads better ':::' or ''. Personally I think both work fine for
me. But I agree with Steph that other people might have a hard time
differenciating them.

--
Slan,
David

Best regards,
Marcus

17 years ago by Steph Fox — view source — reply

unread

Hi Lester,

And there are no problems with those on foreign keyboards?

If there are, those foreign keyboards are unable to offer either escaped
chars or MS paths... which seems highly unlikely.

But do I still understand that there is an alternative method that was not
part of this last round of voting? And needs to be reviewed in light of
the current 'consensus' ?

It was linked from Greg's proposals too:
http://wiki.php.net/rfc/namespaceref. Basically (assuming that we're saying
we want ns support for functions/constants) Stas avoids the need for a
second ns separator by using the syntax

Name->Member

for static access. The 'avoid the need for second ns separator' part of
Stas' proposal has widespread support according to the poll, it's just a
case of figuring a way to manage this without introducing ambiguity into the
code.

Both Stas' proposal and Greg's option #3 are flawed in that way (either to
humans or to the Engine), so the search is on to find a solution that isn't
ambivalent to either - always assuming it's possible.

Steph

17 years ago by Philipp Wagner — view source — reply

unread

Hi,

Steph Fox wrote:

Hi Lester,

And there are no problems with those on foreign keyboards?

If there are, those foreign keyboards are unable to offer either escaped
chars or MS paths... which seems highly unlikely.

Well, on German keyboards, it's accessible but only by using ALTGR+?,
which is not really a comfortable combination.

Philipp

17 years ago by Steph Fox — view source — reply

unread

Well, on German keyboards, it's accessible but only by using ALTGR+?,
which is not really a comfortable combination.

Useful to know, thanks Philipp.

Any more localized keyboard issues we should know about? Anyone?

Steph

17 years ago by Stefan Walk — view source — reply

unread

On Monday 20 October 2008 20:42:36 Steph Fox wrote:

Well, on German keyboards, it's accessible but only by using ALTGR+?,
which is not really a comfortable combination.

Useful to know, thanks Philipp.

Any more localized keyboard issues we should know about? Anyone?

Steph

The "german keyboard" issue isn't really one. {}[] are in the same "class" of
characters (alt-Gr + number-row). So, as a programmer, you either have to
live with that anyway because there's no avoiding {}[], or you switch to the
us layout while programming (which quite a few people do).

Regards,
Stefan

17 years ago by Steph Fox — view source — reply

unread

The "german keyboard" issue isn't really one. {}[] are in the same "class"
of
characters (alt-Gr + number-row). So, as a programmer, you either have to
live with that anyway because there's no avoiding {}[], or you switch to
the
us layout while programming (which quite a few people do).

Also useful to know :)

Steph

17 years ago by olafurw@gmail.com — view source — reply

unread

On an icelandic keyboard "" is AltGr + (key right of 0 in the top
row), just an fyi if you guys wanted to know.

For my two cents. "" looks like its not supposed to be there.

Is there no other combination of two simbols that would work? Like >>
or +> or ** or .. or something in that fashion ?

Ólafur Waage

2008/10/20 Steph Fox steph@php.net:

The "german keyboard" issue isn't really one. {}[] are in the same "class"
of
characters (alt-Gr + number-row). So, as a programmer, you either have to
live with that anyway because there's no avoiding {}[], or you switch to
the
us layout while programming (which quite a few people do).

Also useful to know :)

Steph

17 years ago by Derick Rethans — view source — reply

unread

Steph Fox wrote:

Hi Lester,

And there are no problems with those on foreign keyboards?

If there are, those foreign keyboards are unable to offer either escaped
chars or MS paths... which seems highly unlikely.

Well, on German keyboards, it's accessible but only by using ALTGR+?,
which is not really a comfortable combination.

So in your editor, map ::: to \ and be done with it.... no big deal.

regards,
Derick

--
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

17 years ago by Ilia Alshanetsky — view source — reply

unread

Another issue I just came across caused by :: being used for both
namespaces and classes is the fact when it comes to validation such as
the one I've just put it for constant names, its impossible to
determine if the prefix is a namespace or a class name. So, I
definitely think we should change :: to just about anything else, as
long as its not :: I'd be happy.

Hi Lester,

And there are no problems with those on foreign keyboards?

If there are, those foreign keyboards are unable to offer either
escaped chars or MS paths... which seems highly unlikely.

But do I still understand that there is an alternative method that
was not part of this last round of voting? And needs to be reviewed
in light of the current 'consensus' ?

It was linked from Greg's proposals too: http://wiki.php.net/rfc/namespaceref
. Basically (assuming that we're saying we want ns support for
functions/constants) Stas avoids the need for a second ns separator
by using the syntax

Name->Member

for static access. The 'avoid the need for second ns separator' part
of Stas' proposal has widespread support according to the poll, it's
just a case of figuring a way to manage this without introducing
ambiguity into the code.

Both Stas' proposal and Greg's option #3 are flawed in that way
(either to humans or to the Engine), so the search is on to find a
solution that isn't ambivalent to either - always assuming it's
possible.

Steph

--

Ilia Alshanetsky

17 years ago by Ryan Panning — view source — reply

unread

Ilia Alshanetsky wrote:

Another issue I just came across caused by :: being used for both
namespaces and classes is the fact when it comes to validation such as
the one I've just put it for constant names, its impossible to determine
if the prefix is a namespace or a class name. So, I definitely think we
should change :: to just about anything else, as long as its not :: I'd
be happy.

LOL, this is never ending.

I was on the "change ::" bandwagon before realizing it won't fix
everything. Would changing the element separator help you in this case?
IMO, using a element separator would fix both ambiguity and help
autoload. I'm still for option #2, though it lost out already. ;)

17 years ago by Stan Vassilev | FM — view source — reply

unread

Hi,

Guys, this is like junior school in here.

Let me put some things in perspective:

The location of backslash on foreign keyboard is entirely irrelevant for
the choice of namespace separator. Why? You already use this every day to
escape characters in your strings and regular expressions. Anyone complained
about the location of backslashes in there? No.
Where the backslash is, is also where the {} and [] are on those
kayboards, as some people already said.
"Backslash is ugly" <-- are you honest? Which is uglier: :::Foo()
::Foo() or \Foo(); The last one at least has intuitive meaning (like file
paths: absolute path). Face it that you'll be typing either one of the above
three a lot, and pick one that makes sense visually and for newcomers
alike. I think that's the backslash.
"But we want the same operator". Well? I want a pony, the fact is
however, the other languages have the design to afford the same separator
for namespaces, static methods and members. Shoehorning this in PHP while
maintaing BC will create such nightmares in big projects with ambigous
identifiers, autoload performance issues, that you'd wish you go back and
change the damn namespace operator to just about anything but "::".

I wish the people who have a clear opinion of the above voice their opinion.
For those who aren't quite sure what the issues in point 4 are, please just
stay low and follow the list until you do.

Regards,
Stan Vassilev

17 years ago by Vesselin Kenashkov — view source — reply

unread

The N word discussion looks neverending...
solution #3 from Gregory solves the ambiguity so I dont see how it will
"create such nightmares in big projects with ambigous identifiers". I'm
using the :: operator for the last 6 months and I had no such issues even
without the fix (I'm not naming classes and namespaces in the same way, and
I dont see why I would need to do so). Have you tried using it?
If the __autoload performance problem is solved I dont see what is the
problem with the current separator. I would wait for the opinion of Gregory
and Stas Malyshev on this matter.
On the other hand I dont think the backslash is ugly, and I think that the
windows users will find it somewhat familiar for using it in tree structures
like the namespaces.

On Tue, Oct 21, 2008 at 10:33 AM, Stan Vassilev | FM
sv_forums@fmethod.comwrote:

Hi,

Guys, this is like junior school in here.

Let me put some things in perspective:

The location of backslash on foreign keyboard is entirely irrelevant for
the choice of namespace separator. Why? You already use this every day to
escape characters in your strings and regular expressions. Anyone complained
about the location of backslashes in there? No.

Where the backslash is, is also where the {} and [] are on those
kayboards, as some people already said.

"Backslash is ugly" <-- are you honest? Which is uglier: :::Foo()
::Foo() or \Foo(); The last one at least has intuitive meaning (like file
paths: absolute path). Face it that you'll be typing either one of the above
three a lot, and pick one that makes sense visually and for newcomers
alike. I think that's the backslash.

"But we want the same operator". Well? I want a pony, the fact is
however, the other languages have the design to afford the same separator
for namespaces, static methods and members. Shoehorning this in PHP while
maintaing BC will create such nightmares in big projects with ambigous
identifiers, autoload performance issues, that you'd wish you go back and
change the damn namespace operator to just about anything but "::".

I wish the people who have a clear opinion of the above voice their
opinion. For those who aren't quite sure what the issues in point 4 are,
please just stay low and follow the list until you do.

Regards,
Stan Vassilev

--

--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com

17 years ago by Arvids Godjuks — view source — reply

unread

2008/10/21 Stan Vassilev | FM sv_forums@fmethod.com

Hi,

Guys, this is like junior school in here.

Let me put some things in perspective:

The location of backslash on foreign keyboard is entirely irrelevant for
the choice of namespace separator. Why? You already use this every day to
escape characters in your strings and regular expressions. Anyone complained
about the location of backslashes in there? No.

Where the backslash is, is also where the {} and [] are on those
kayboards, as some people already said.

"Backslash is ugly" <-- are you honest? Which is uglier: :::Foo()
::Foo() or \Foo(); The last one at least has intuitive meaning (like file
paths: absolute path). Face it that you'll be typing either one of the above
three a lot, and pick one that makes sense visually and for newcomers
alike. I think that's the backslash.

"But we want the same operator". Well? I want a pony, the fact is
however, the other languages have the design to afford the same separator
for namespaces, static methods and members. Shoehorning this in PHP while
maintaing BC will create such nightmares in big projects with ambigous
identifiers, autoload performance issues, that you'd wish you go back and
change the damn namespace operator to just about anything but "::".

I wish the people who have a clear opinion of the above voice their
opinion. For those who aren't quite sure what the issues in point 4 are,
please just stay low and follow the list until you do.

Regards,
Stan Vassilev

--

Exactly my feeling. When it comes to dealings with 15+ MB codes (after
excluding all 3-rd parity libraries), ambiguity problem becomes real even
now. It's hard enough to think of good name for 2 similar, but different in
realisation modules, so that you understand what they are for and to
understand what is different between them. I deal with 3 projects 50 MB +-
in size every day, jumping from one to other sometimes few times a day. such
projects 100% have large amount of variables named equaly. If you begin to
implement namespace support and access them outside namespaces, it becomes a
nightmare to understand what it accessed.
I see two solutions:
1). Change the separator.
2). Don't allow function, class, constant and variable naming same as
namespace name. Make it a fatal error. Then this will be solved.

Other options like throwing something away or make an ambigity resolution
mechanism personaly me don't make happy. Throwing something away leaves us
with something half working. Ambigity resolution mechanism makes us to
remember what is what (scrolling up and down tens of times a day is realy
disturbing the work), but is for sure better than first one.

If we combine all good things from all proposals, we can get one big solid
thing. Just my IMHO, but still:
1). Change the separator.
2). Make resolution to global classes, functions, constants first and if not
found - then to namespace. But realy, may be use self to point to namespaced
function, class, method ? Same as $this in classes. That seems logical,
because PHP is already using such mechanism.
3). Don't allow ambigity naming. Die with E_FATAL in such cases, don't allow
thouse coders to write bad code, please do! I beg you!

I don't know how parser works exactly, but maybe constant ambigity could be
resolved by patch, witch resolves constant values at compile time. If that
can't be done, than issue E_FATAL.

Just my IMHO. Please, don't make a holly war of my post. I wount argue with
holly war responces. Just tell me where I'm wrong and if that's because of
implementation difficulties - explain, I will understand that techno bable
:)

17 years ago by Steph Fox — view source — reply

unread

Hi,

Guys, this is like junior school in here.

Yep.

Let me put some things in perspective:

No, let me. Greg worked his butt off the entire weekend looking for the
flaws in all the options available to us, including a couple of new ones
that never even reached the list before he rejected them on technical
grounds. Thanks to his efforts, we already have a pretty good picture of the
strengths and weaknesses of each approach - and as should be obvious to all
by now, there is no perfect solution. Whatever we chose, it's a compromise.

What we're hearing here about European keyboard layouts is useful info
because it gives some idea of how popular/unpopular the backslash would be
as a solution and why, but it shouldn't carry as much weight as the
accessibility argument against the triple colon. One is liveable, if not
optimal, whereas the other is plainly not liveable for some. We've already
heard two workarounds for the backslash issues, but there are none at all
for ::: + imperfect eyesight.

Clarity and simplicity are the two chief requisites. We're all fully aware
of that, from Engine developer to n00b, so there's really no point in
discussing it to death on-list at this stage.

Steph

17 years ago by Catalin Zamfir Alexandru | KIT Software CAZ — view source — reply

unread

Clarity and simplicity are the two chief requisites. We're all fully
aware
of that, from Engine developer to n00b, so there's really no point in
discussing it to death on-list at this stage.

Yep. I agree. I'm already tired of watching this thread. Let them agree
on an implementation that is going to work with THE LEAST AMOUNT of cons. -
because some of us (that means me) really just want namespaces implemented, and
for one reason it doesn't really count what 'sign' it's used to mark a namespace,
as much as the functionality they bring.

As long as my PHP job depends on developing extremelly simple methods/functions
for our noobish PHP developers, namespaces are a great functionality needed to
map 'same-name functions/methods' to a freakin' namespace that would be simple to
use for the average PHP developer.

So, my Nike-borrowed motto is: "Just do it (already!) ..." ...

17 years ago by Lester Caine — view source — reply

unread

Steph Fox wrote:

What we're hearing here about European keyboard layouts is useful info
because it gives some idea of how popular/unpopular the backslash would
be as a solution and why, but it shouldn't carry as much weight as the
accessibility argument against the triple colon. One is liveable, if not
optimal, whereas the other is plainly not liveable for some. We've
already heard two workarounds for the backslash issues, but there are
none at all for ::: + imperfect eyesight.

I should probably apologise for bringing up the keyboard question, but I did
so purely because a number of people had mentioned the problem. I was just
trying to refer to the general problem that while many of the symbols used are
on US keyboards, they may well be used for local characters on other layouts,
and can be difficult to access for some developers. I was just trying to flag
a general problem that is often ignored rather than the specific /::: one.

Clarity and simplicity are the two chief requisites. We're all fully
aware of that, from Engine developer to n00b, so there's really no point
in discussing it to death on-list at this stage.

Have we reached a consensus? Or is this still a little open ended?

--
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

17 years ago by Lester Caine — view source — reply

unread

Steph Fox wrote:

Have we reached a consensus? Or is this still a little open ended?

Scott's trying to pull together a developer-only meeting so we can look
at what's left in a bit more depth. Once we've done this it'll probably
come back to the list (should, IMHO).

Timezones, timezones....!

Don't start another long debate ;)
Pigging time offset in browser is useless for determining timezone/DSL :)

--
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

Namespace issues View as Markdown

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL