hi stanislav,
On Wednesday 17 October 2007 02:08:06 am Stanislav Malyshev wrote:
> > yes, this is of course a big deal for some people, esp if you're using
> > proprietary software that's built against the "original" abi. of course
> > if you're only using OSS extensions, you can simply recompile
On Tuesday 16 October 2007 04:37:57 pm Wez Furlong wrote:
> PHP's native integer type is long, how else are you going to relay
> numbers longer than a long back to the script without rewriting the
> engine to add additional integer types, which is a massive changeset?
okay, chalk this up to my IAN
suit fully fitted) "catch-up". (Hey when has documentation EVER been
ahead of the game!?!).
Always? Otherwise there would be no need for documentation, if
everything was in the code. Some people even start with writing docs and
only then implement the actual code. Of course, it is not always t
yes, this is of course a big deal for some people, esp if you're using
proprietary software that's built against the "original" abi. of course if
you're only using OSS extensions, you can simply recompile them against the
new api/abi and there's no drawback.
That's not only about OSS vs. prop
You might have a point there; I'd assumed that CFLAGS made it through
to php-config, but it doesn't look like they do.
It should be a simple matter to define them in php_config.h instead.
--Wez.
On Oct 16, 2007, at 6:16 PM, Stanislav Malyshev wrote:
Yes, the patch does that; it turns on LFS i
Yes, the patch does that; it turns on LFS in the headers, which promotes
the off_t and size_t types that are used by streams to the 64-bit
versions. This is the one liner in configure.in.
The other larger part of the patch is to make PHP functions capable of
returning and accepting numbers that
With thanks to Sara we looked at OnUpdateUTF8String to access a
php.ini value in OCI8 in PHP 6.
One of our engineers sent me a proposed patch for zend_ini.c in PHP6
to allow OnUpdateUTF8String to work as he thought it should. Any
comments?
Chris
> The problems I faced when unico
On Oct 16, 2007, at 2:44 AM, sean finney wrote:
i would suggest that anywhere where one is doing something with a
size or
offset and not using the posix size_t/off_t types should get such
changes.
and like i said, i don't see the motivation behind this extra step of
returning the size in d
On 16.10.2007, at 15:09, Hans Moog wrote:
When it comes to interoperation between systems and or developers,
it is always a
good idea to define strict standards of how the communication
between libarys and components
has to take place (since public methods are something like an
interface
>The point is that I do not see this feature at all relevant to
>solving the web problem. This is where PHP needs to focus. Namespaces
>help in solving the web problem, because it eases cooperation of
>independent developers to supply libraries. The feature you are
>proposing is solved easi
On 16.10.2007, at 13:43, Hans Moog wrote:
I agree. But PHP (until PHP 5.2.x) was the wrong language for
everyone who wanted to use namespaces, too.
But a programming language is able to evolve and sometimes new
features are really usefull and should be included. And in this
special case
>> And if you have more than one parameter you will name it
>> methodFromStringIntegerSampleClassBoolean ?!?
>
>No, I would rethink my interface.
Sometimes you need more than one parameter and even rethinking wouldn't "solve"
this requirement.
>> And how would you do the same for constructors ?!
Hans Moog wrote:
> And if you have more than one parameter you will name it
> methodFromStringIntegerSampleClassBoolean ?!?
No, I would rethink my interface.
> And how would you do the same for constructors ?!? Create a
> initWithStringIntegerSampleClassBoolean method which has to be called
> aft
And if you have more than one parameter you will name it
methodFromStringIntegerSampleClassBoolean ?!?
And how would you do the same for constructors ?!? Create a
initWithStringIntegerSampleClassBoolean method which has to be called after
object creation ?!?
-Ursprüngliche Nachricht-
Hans Moog wrote:
When it would be:
==
function xpath(DomDocument $arg) {
return new DomXPath($arg);
}
function xpath(XmlTree $arg) {
return new DomXPath($this->loadXML($arg->getSource(;
}
function xpath(string $arg) {
return new DomXPath($this->loadXML($arg));
}
==
On 15/10/2007, Hans Moog <[EMAIL PROTECTED]> wrote:
> When it would be:
>
> ==
> function xpath(DomDocument $arg) {
> return new DomXPath($arg);
> }
>
> function xpath(XmlTree $arg) {
> return new DomXPath($this->loadXML($arg->getSource(;
> }
>
> function xpath(string $arg) {
On Mon, 2007-10-15 at 19:03 -0300, Cristian Rodriguez wrote:
> 2007/10/15, Antony Dovgal <[EMAIL PROTECTED]>:
> > "Thank you"?
>
> Rarely, as the year advances, people is getting more and more stressed
> and is certainly not fun to deal with the reports.
It's fun to certain point. I've also come
http://news.php.net/php.internals/32789
On 15/10/2007, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> "Thank you"? I can't recall when I heard it last time.
Really, how about right now!
Unconditionally and without reservation, I would like to take this
opportunity to say thank you to every single de
It allows you to be strict when messing with types but it doesn't allow you to
overload type hinted methods ... so this is no solution to the problem of
overloading type hinted methods, is it ?
-Ursprüngliche Nachricht-
Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Gesendet: Mo 15.1
19 matches
Mail list logo
