Unknown W. Brackets wrote:

> I write forum software in PHP which utilizes MySQL, as I've mentioned before.  I help provide support.  If *nothing else*, I can attest: just because updates are free, doesn't mean:
>   - competing compiler vendors (e.g. writing the only QNX version) will update.
>   - everyone, especially people who are not full-time developers will update.
>   - people will even bother to check/know if they are using an old version.

Or:
- That the time that it takes the people to perform the update is free
- That the brand new version will actually work, and will work better
- That the fixes in the new version doesn't introduce brand new bugs

Life on the "bleeding edge" is sometimes pretty painful...
Better then to use an old version, with security patches ?
Lots of distributions freeze the version numbers for years.

--anders

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:d87d35$2at4$1@digitaldaemon.com...
> Just my opinion, though.  And, no, I'm not being so helpful as proposing a solution.

I know upgrades that require source code changes suck. But I hope you'll find that this one is worth it.

Good catch. Fixed.

In this case, 4.3.11 is/was a security fix release.  There are security holes in all of the old versions - and not only have they not updated, they have not even compiled in patches or anything.  These are old, insecure, virgin compiles of PHP.  I'll never understand it - but it definately happens.

-[Unknown]


> Or:
> - That the time that it takes the people to perform the update is free
> - That the brand new version will actually work, and will work better
> - That the fixes in the new version doesn't introduce brand new bugs
> 
> Life on the "bleeding edge" is sometimes pretty painful...
> Better then to use an old version, with security patches ?
> Lots of distributions freeze the version numbers for years.
> 
> --anders

Egads, how'd I miss this announcement?  It's like Christmas!  Quick question: when "delete map[key]" goes away completely, will it begin to function like a normal delete operation?  ie. will it delete the referenced class and set the hashed value to null?


Sean

"Walter" <newshound@digitalmars.com> wrote in message news:d868t4$18rh$1@digitaldaemon.com...
>
> "Derek Parnell" <derek@psych.ward> wrote in message news:8hj4a6bljgap$.1jlptuycpjghd.dlg@40tude.net...
>> Well done...I thought you'd been quiet for awhile ;-)
>
> Thanks!
>
>> I especially like the way you are prepared to allow potentially
> 'dangerous'
>> behaviour and explain why it is so (re: Void Initializers). This shows
> that
>> D is willing to trust the advanced coder who knows what they are doing.
>
> The idea is not to disallow such behavior, like Pascal and Java do, but to make such practices obvious in the code and not the default. Potentially 'dangerous' behavior should be coded in on purpose, not inadvertently, and should be identifiable with a visual inspection of the code.

absolutely true, IMHO. As much code is compact and obvious as better
to visual inspect it and get an idea of what is going on - thus
to write reliable code. And this is why D is so attractible now.

Having said that and using "practices obvious in the code" motto I am thinking about have a question:

Currently following:

const char[] s = "Hello";
    s[0] = 0;

compiles just fine.

What is l-value then in terms of D considering
that arrays are built-in in its type system?

I read history of D discussions about const's, got your and your opponents points, etc.

I understand that it is too difficult
(read almost impossible to get fast and reliable compiler)
to cover current C++ const cases. And I agree that current
const system in C++ is overkill and is not
good at all as it contradicts with "practices obvious
in the code". Especially in complex class hierachies
and systems.

Considering that arrays are both values and references
then type system should include const content
accent modifier for them like:

   char#[] str;  // array type without
                      // opIndexAssign etc. - immutable array.
                      // # char means here literally:
                      // no opIndexAssign modifying its content.

Such solution don't need current const syntax redesign
so pretty minor. I guess that pointers like char#* could
also be made this way.

T#[] and T[] are two distinct types "auto castible"
in the direction  T#[] <- T[].

Andrew.

Quick question about the documentation... in the docs for the 'is' expression:

alias int func(int);	// func is a alias to a function type

Shouldn't this be:

alias int function(int) func;	// func is a alias to a function type


Sean

I didn't mean to imply it wasn't - and, in this time, while D is not yet "stable" and has not reached 1.0, it's fine.  I don't mind the version clashes one bit.

It's after 1.0 that I will, should another occur at that time.  And I would want other, good, worthwhile updates too - not a cold stop at 1.0 and no prospect of a 2.0.

-[Unknown]


> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message
> news:d87d35$2at4$1@digitaldaemon.com...
> 
>>Just my opinion, though.  And, no, I'm not being so helpful as proposing
>>a solution.
> 
> 
> I know upgrades that require source code changes suck. But I hope you'll
> find that this one is worth it.
> 
> 

"Sean Kelly" <sean@f4.ca> wrote in message news:d87fqr$2du8$1@digitaldaemon.com...
> Quick question about the documentation... in the docs for the 'is'
expression:
>
> alias int func(int); // func is a alias to a function type
>
> Shouldn't this be:
>
> alias int function(int) func; // func is a alias to a function type

No, the latter declares func to be a *pointer* to a function type.

"Sean Kelly" <sean@f4.ca> wrote in message news:d87ffi$2dac$1@digitaldaemon.com...
> Egads, how'd I miss this announcement?  It's like Christmas!  Quick
question:
> when "delete map[key]" goes away completely, will it begin to function
like a
> normal delete operation?  ie. will it delete the referenced class and set
the
> hashed value to null?

Yes.