Re: [objc-improvements-branch] About to start ObjC++

Re: [objc-improvements-branch] About to start ObjC++

[Dara Hazeghi]

> I actually don't mind the idea of ObjC, although > I
will probably only  use it 
> minimistically..what I take issue with, 
> specifically, is the fact  that
> you have carte blanche control over anything 
> objc related in GCC, and  you
> act like a lord, dictating what will happen and >
when, instead of  working with people.

I don't like to butt into threads like this, but what
is the problem here? We explicitly allow developers to
create branches on which they specify the check-in
criteria. We do this precisely for occurrences like
this, to develop or integrate a specific feature.
Would it help us if Zem just sent in a single massive
patch to gcc-patches, and nobody got a chance to
test/comment on the code before it gets reviewed and
merged onto mainline?

In any case, rather than hurling around accusationas,
if there are specific patches/issues you'd like
addressed, perhaps you could specify what they are?
Cheers,

Dara

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Re: [objc-improvements-branch] About to start ObjC++

[Marcel Weiher]

Oops, I missed it, it's actually stil there...

On 22 Jan 2004, at 00:33, Marcel Weiher wrote:

> Anyway, I see that the integrated runtime job is no longer on offer... 
> :-)
>
-- 
Marcel Weiher				Metaobject Software Technologies
marcel@metaobject.com		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.
		1d480c25f397c4786386135f8e8938e4

Re: [objc-improvements-branch] About to start ObjC++

[Marcel Weiher]

On 21 Jan 2004, at 20:13, Mike Stump wrote:

> On Wednesday, January 21, 2004, at 08:52 AM, Pascal J.Bourguignon 
> wrote:
>> David Ayers writes:
>>> Hmm, is this a subtle suggestion that 'you' ('we' as in Apple?) would
>>> prefer to only have ObjC++?  Call me paranoid but that thought alone 
>>> is
>>> quite frightening. :-) (But also currently irrelevant.)
>>
>> Of course not. I assume Apple would like to have a JavObjC++! :-)
>
> A curious idea, would you like to implement it?  :-)

Sort of, though I am not particulary fond of Java (less now that I work 
with it full-time...).

I did look at the issues a little when I learned about gcj, and it 
seemed quite possible to integrate the gcj and Objective-C runtimes 
with only fairly minor tweaks.

Having worked extensively with Squeak and created the CocoaSqueak VM, 
integration with Smalltalk (or a simplified Objective-Smalltalk) also 
looks like a lovely option.

Anyway, I see that the integrated runtime job is no longer on offer... 
:-)

Cheers,

Marcel

Re: [objc-improvements-branch] About to start ObjC++

[Ziemowit Laski]

On 21 Jan, 2004, at 3.08, David Ayers wrote:

> Ziemowit Laski wrote:
>
>> Hello,
>>
>> This is just a friendly heads-up that the objc-improvements-branch,
>> previously used to integrate Apple's ObjC fixes into the mainline,
>> shall henceforth be used to develop the Objective-C++ front-end,
>> to be integrated into mailine 3.5 upon completion.
>
> Hello Zem,
>
> Thanks, I have a few questions which you could maybe address.
>
> Will the objc++ frontend work with the GNU runtime?
> If not, will you accept patches to the branch to make it work, even if 
> this entails restructuring the code in general (potentially even 
> require tweaking the NeXT/Apple runtime)?

I see absolutely no reason why the GNU runtime should be affected, 
since ObjC++ will be using the objc-act.c bits already in place.  
Irrespective of that, you are of course welcome to submit patches 
and/or suggestions. :-)

> Are there any other platform dependencies that you are already aware 
> of (i.e. other that the potential dependency on the Apple Runtime)?
> IIRC, it was mentioned, that this is a new frontend which will make 
> use of some of the source files (e.g. objc-act.c) in the current objc 
> frontend.  I expect that there are some tweaks needed, so we should 
> continue testing the objc frontend of the branch, right?

It can't hurt, although any changes to objc-act.c will most likely be 
C++-specific (and C++-conditional), so there shouldn't be much of a 
problem.

>
> Are you planing to do the merge into mainline in coherent pieces or an 
> all-in-one merge as previously?  (In which case, I would like to 
> kindly ask you to post not only meaningful ChangeLogs, but the patches 
> to the branch itself, please.)

OK, I'll post the diffs along with the ChangeLogs.
>
> Also, FYI, now that mainline is open again, I'm planning to bring some 
> of the cleanup patches and Class <Protocol> support from last year 
> back up to date, as soon as I can spare some cycles. (It might take 
> two or three weeks from now though.)

Sure; that would be great!

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Re: [objc-improvements-branch] About to start ObjC++

[Mike Stump]

On Wednesday, January 21, 2004, at 08:52 AM, Pascal J.Bourguignon wrote:
> David Ayers writes:
>> Hmm, is this a subtle suggestion that 'you' ('we' as in Apple?) would
>> prefer to only have ObjC++?  Call me paranoid but that thought alone 
>> is
>> quite frightening. :-) (But also currently irrelevant.)
>
> Of course not. I assume Apple would like to have a JavObjC++! :-)

A curious idea, would you like to implement it?  :-)

Re: [objc-improvements-branch] About to start ObjC++

[steve naroff]

> Hmm, is this a subtle suggestion that 'you' ('we' as in Apple?) would 
> prefer to only have ObjC++?

Actually, not me or Apple..."we" in this context refers to many folks 
in the C/C++ language communities who wanted to resolve subtle 
incompatibilities between C++ and ANSI-C (on the features that 
overlapped). Instead, the incompatibilities persist and ANSI-C has 
adopted a subset of the C++ features. This indirectly effects the 
ObjC++ issue.

 From an implementation perspective, it would be really great to have 
ONE C language front-end (Apple currently ships 4...cc1, cc1obj, 
cc1plus, cc1objplus). Having 4 creates a maintenance burden and can 
hurt performance.

> Call me paranoid but that thought alone is quite frightening. :-) (But 
> also currently irrelevant.)

As you say, it is currently irrelevant. C and C++ will forever be 
distinct (oh well).

snaroff

On Jan 21, 2004, at 8:05 AM, David Ayers wrote:

> Hello Steve,
>
> steve naroff wrote:
>
>> When ObjC++ was written, there was thought/hope that the ANSI-C and 
>> ANSI-C++ standardization efforts would "converge" (and it would 
>> become the "modern" dialect). Since they never did, we are left with 
>> two dialects of ObjC (unfortunately...we would prefer to have one:-)
>
> Hmm, is this a subtle suggestion that 'you' ('we' as in Apple?) would 
> prefer to only have ObjC++?  Call me paranoid but that thought alone 
> is quite frightening. :-) (But also currently irrelevant.)
>
>> Here are some answers to your questions...
>>
>>> Will the objc++ frontend work with the GNU runtime?
>>
>>
>> Yes. Objective-C++ didn't require any changes to the Apple 
>> runtime...the same should be true for the GNU runtime.
>
> This is wonderful news!
>
>>> Are there any other platform dependencies that you are already aware 
>>> of (i.e. other that the potential dependency on the Apple Runtime)?
>>
>>
>> No.
>
> Even better!
>
>>> IIRC, it was mentioned, that this is a new frontend which will make 
>>> use of some of the source files (e.g. objc-act.c) in the current 
>>> objc frontend.  I expect that there are some tweaks needed, so we 
>>> should continue testing the objc frontend of the branch, right?
>>
>>
>> Absolutely. Layering ObjC atop C++ can potentially introduce 
>> regressions...
>>
>>
> OK, so once things stabilize on the branch, I'll see if I can churn it 
> through GNUstep.
>
> Thanks,
> David
>
> PS: I realize that ObjC++ has a history on NeXT/Apple's platforms and 
> that you'll want 'your' (aka Apple's) version to be binary compatible 
> on Darwin.  So if it turns out that there are quirks that show up on 
> other platforms we should try to solve them in binary compatible 
> fashion wrt Darwin if elegantly possible but I hope you agree with me, 
> that the FSF tree may diverge to gain more portability as there is 
> nothing to be backward compatible too wrt to ObjC++ on anything but 
> Darwin.  But from your assurances, I'll assume that this currently a 
> non-issue.
>

Re: [objc-improvements-branch] About to start ObjC++

[Pascal J.Bourguignon]

David Ayers writes:
> Hmm, is this a subtle suggestion that 'you' ('we' as in Apple?) would 
> prefer to only have ObjC++?  Call me paranoid but that thought alone is 
> quite frightening. :-) (But also currently irrelevant.)

Of course not. I assume Apple would like to have a JavObjC++! :-)

-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

Re: [objc-improvements-branch] About to start ObjC++

[David Ayers]

Hello Steve,

steve naroff wrote:

> When ObjC++ was written, there was thought/hope that the ANSI-C and 
> ANSI-C++ standardization efforts would "converge" (and it would become 
> the "modern" dialect). Since they never did, we are left with two 
> dialects of ObjC (unfortunately...we would prefer to have one:-)

Hmm, is this a subtle suggestion that 'you' ('we' as in Apple?) would 
prefer to only have ObjC++?  Call me paranoid but that thought alone is 
quite frightening. :-) (But also currently irrelevant.)

> Here are some answers to your questions...
>
>> Will the objc++ frontend work with the GNU runtime?
>
>
> Yes. Objective-C++ didn't require any changes to the Apple 
> runtime...the same should be true for the GNU runtime.

This is wonderful news!

>> Are there any other platform dependencies that you are already aware 
>> of (i.e. other that the potential dependency on the Apple Runtime)?
>
>
> No.

Even better!

>> IIRC, it was mentioned, that this is a new frontend which will make 
>> use of some of the source files (e.g. objc-act.c) in the current objc 
>> frontend.  I expect that there are some tweaks needed, so we should 
>> continue testing the objc frontend of the branch, right?
>
>
> Absolutely. Layering ObjC atop C++ can potentially introduce 
> regressions...
>
>
OK, so once things stabilize on the branch, I'll see if I can churn it 
through GNUstep.

Thanks,
David

PS: I realize that ObjC++ has a history on NeXT/Apple's platforms and 
that you'll want 'your' (aka Apple's) version to be binary compatible on 
Darwin.  So if it turns out that there are quirks that show up on other 
platforms we should try to solve them in binary compatible fashion wrt 
Darwin if elegantly possible but I hope you agree with me, that the FSF 
tree may diverge to gain more portability as there is nothing to be 
backward compatible too wrt to ObjC++ on anything but Darwin.  But from 
your assurances, I'll assume that this currently a non-issue.

Re: [objc-improvements-branch] About to start ObjC++

[steve naroff]

David,

I work with Zem and will chime in here (and help answer your 
questions...).

I wrote the ObjC frontend and NeXT/Apple runtime in 1988. Objective-C++ 
was written in the summer of 1989 to support the development of Lotus 
Improv (initially).

The reason the background is interesting is the 
following...Objective-C++ has been successfully used within the 
NeXT/Apple community for almost 15 years! That is, Objective-C++ isn't 
research...it is a product that has been in used for many years now. As 
a result, we care about source compatibility.

When ObjC++ was written, there was thought/hope that the ANSI-C and 
ANSI-C++ standardization efforts would "converge" (and it would become 
the "modern" dialect). Since they never did, we are left with two 
dialects of ObjC (unfortunately...we would prefer to have one:-) Here 
are some answers to your questions...

> Will the objc++ frontend work with the GNU runtime?

Yes. Objective-C++ didn't require any changes to the Apple 
runtime...the same should be true for the GNU runtime.

> If not, will you accept patches to the branch to make it work, even if 
> this entails restructuring the code in general (potentially even 
> require tweaking the NeXT/Apple runtime)?
> Are there any other platform dependencies that you are already aware 
> of (i.e. other that the potential dependency on the Apple Runtime)?

No.

> IIRC, it was mentioned, that this is a new frontend which will make 
> use of some of the source files (e.g. objc-act.c) in the current objc 
> frontend.  I expect that there are some tweaks needed, so we should 
> continue testing the objc frontend of the branch, right?

Absolutely. Layering ObjC atop C++ can potentially introduce 
regressions...

Hope this helps,

snaroff

On Jan 21, 2004, at 3:08 AM, David Ayers wrote:

> Ziemowit Laski wrote:
>
>> Hello,
>>
>> This is just a friendly heads-up that the objc-improvements-branch,
>> previously used to integrate Apple's ObjC fixes into the mainline,
>> shall henceforth be used to develop the Objective-C++ front-end,
>> to be integrated into mailine 3.5 upon completion.
>
> Hello Zem,
>
> Thanks, I have a few questions which you could maybe address.
>
> Will the objc++ frontend work with the GNU runtime?
> If not, will you accept patches to the branch to make it work, even if 
> this entails restructuring the code in general (potentially even 
> require tweaking the NeXT/Apple runtime)?
> Are there any other platform dependencies that you are already aware 
> of (i.e. other that the potential dependency on the Apple Runtime)?
> IIRC, it was mentioned, that this is a new frontend which will make 
> use of some of the source files (e.g. objc-act.c) in the current objc 
> frontend.  I expect that there are some tweaks needed, so we should 
> continue testing the objc frontend of the branch, right?
>
> Are you planing to do the merge into mainline in coherent pieces or an 
> all-in-one merge as previously?  (In which case, I would like to 
> kindly ask you to post not only meaningful ChangeLogs, but the patches 
> to the branch itself, please.)
>
> Also, FYI, now that mainline is open again, I'm planning to bring some 
> of the cleanup patches and Class <Protocol> support from last year 
> back up to date, as soon as I can spare some cycles. (It might take 
> two or three weeks from now though.)
>
> Cheers,
> David
>
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep

Re: [objc-improvements-branch] About to start ObjC++

[David Ayers]

Ziemowit Laski wrote:

> Hello,
>
> This is just a friendly heads-up that the objc-improvements-branch,
> previously used to integrate Apple's ObjC fixes into the mainline,
> shall henceforth be used to develop the Objective-C++ front-end,
> to be integrated into mailine 3.5 upon completion.

Hello Zem,

Thanks, I have a few questions which you could maybe address.

Will the objc++ frontend work with the GNU runtime?
If not, will you accept patches to the branch to make it work, even if 
this entails restructuring the code in general (potentially even require 
tweaking the NeXT/Apple runtime)?
Are there any other platform dependencies that you are already aware of 
(i.e. other that the potential dependency on the Apple Runtime)?
IIRC, it was mentioned, that this is a new frontend which will make use 
of some of the source files (e.g. objc-act.c) in the current objc 
frontend.  I expect that there are some tweaks needed, so we should 
continue testing the objc frontend of the branch, right?

Are you planing to do the merge into mainline in coherent pieces or an 
all-in-one merge as previously?  (In which case, I would like to kindly 
ask you to post not only meaningful ChangeLogs, but the patches to the 
branch itself, please.)

Also, FYI, now that mainline is open again, I'm planning to bring some 
of the cleanup patches and Class <Protocol> support from last year back 
up to date, as soon as I can spare some cycles. (It might take two or 
three weeks from now though.)

Cheers,
David

Re: [objc-improvements-branch] About to start ObjC++

[Markus Hitter]

Am 20.01.2004 um 21:54 schrieb Alex Perez:

> Pardon me, but are you completely blind to the discussions about 
> greater openness that we've been having in here over the last several 
> weeks, ...

Difference between him and some others is, Zem discusses actual code. 
He implements a solution for a gcc improvment, then offers this code 
for discussion. This is how things get improved instead of being 
discussed only.

ObjC++ is on the wishlist of many people. If you don't like 
Zem's/Apple's solution, discuss it, improve it or come up with your 
own. If you don't have the time to do so now, keep your nice wording 
and offer your better solution later.


> On Tue, 20 Jan 2004, Ziemowit Laski wrote:
>
>> This is just a friendly heads-up ...
>>
>> Once objc-improvements-branch becomes even minimally usable, I'll 
>> send out another notice so that folks can try it out.

... and discuss it.

Great.


Cheers,
Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/

Re: [objc-improvements-branch] About to start ObjC++

[Ziemowit Laski]

On 20 Jan, 2004, at 15.31, Alexander Malmberg wrote:

> Ziemowit Laski wrote:
>> Hello,
>>
>> This is just a friendly heads-up that the objc-improvements-branch,
>> previously used to integrate Apple's ObjC fixes into the mainline,
>> shall henceforth be used to develop the Objective-C++ front-end,
>> to be integrated into mailine 3.5 upon completion.
>
> I assume the branch will be used only for objective-c++, and that any
> other objective-c changes (ie. that affect normal objective-c) will be
> separated out for review; right? I have a big interest in keeping
> objective-c working for us (GNUstep and related projects), but since I
> don't have a real interest in objective-c++ per se, I'm not going to
> track the branch and test/fix the GNU runtime side of things (unlike
> last time).

There is a small chance that there may be some NeXT-only ObjC fixes in
addition to ObjC++.  Of course, if/when objc-improvements-branch is 
ready
to be integrated into mainline, _all_ of it will be subject to review. 
:-)

Also, as I commit things, I can send copies of the ChangeLog to 
gcc-patches,
so that you can get a bird's eye view of what is happening.  Would that 
be helpful?

Thanks,

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Re: [objc-improvements-branch] About to start ObjC++

[Alexander Malmberg]

Ziemowit Laski wrote:
> Hello,
> 
> This is just a friendly heads-up that the objc-improvements-branch,
> previously used to integrate Apple's ObjC fixes into the mainline,
> shall henceforth be used to develop the Objective-C++ front-end,
> to be integrated into mailine 3.5 upon completion.

I assume the branch will be used only for objective-c++, and that any
other objective-c changes (ie. that affect normal objective-c) will be
separated out for review; right? I have a big interest in keeping
objective-c working for us (GNUstep and related projects), but since I
don't have a real interest in objective-c++ per se, I'm not going to
track the branch and test/fix the GNU runtime side of things (unlike
last time).

- Alexander Malmberg

Re: [objc-improvements-branch] About to start ObjC++

[Ziemowit Laski]

On 20 Jan, 2004, at 13.55, Alex Perez wrote:

> On Tue, 20 Jan 2004, Ziemowit Laski wrote:
>> If you don't like ObjC++, you certainly don't have to use it! :-)  I
>> honestly don't know what your issue is here...
>
> I actually don't mind the idea of ObjC, although I will probably only 
> use
> it minimistically..what I take issue with, specifically, is the fact 
> that
> you have carte blanche control over anything objc related in GCC, and 
> you
> act like a lord, dictating what will happen and when, instead of 
> working
> with people. I understand that this is a viable model (and often quite
> necessary) in many corporations, but it is not how the FSF generally 
> does
> business, and I ask that you kindly recognize that and act in 
> cooperation
> with others, instead of just dictatinig, which is what you're doing 
> now.

Dude, you'll have to be specific here.  If there is something 
_specifically_
wrong that you think I'm doing, please share it with us.  But I must 
tell
you that I tend to ignore vague, gadfly-like criticism like the 
foregoing.
>
> Just to clear up misconceptions, I have absolutely no problem with you
> personally nor with the idea of ObjC++. The last time you comitted a 
> bunch
> of stuff, you broke the GNU ObjC runtime in your branch because you 
> were
> (IMHO) careless, and I do not wish to see a repeat performance of that.

I think you may have a minor misconception as to the purpose of
objc-improvements-branch.  It is a _development_ branch, among many
others, and as such contains work in progress, which may at times
be partially (or even completely) broken.  It is _not_ a release
branch.

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Re: [objc-improvements-branch] About to start ObjC++

[Alex Perez]

On Tue, 20 Jan 2004, Ziemowit Laski wrote:
> If you don't like ObjC++, you certainly don't have to use it! :-)  I 
> honestly don't know what your issue is here...

I actually don't mind the idea of ObjC, although I will probably only use 
it minimistically..what I take issue with, specifically, is the fact that 
you have carte blanche control over anything objc related in GCC, and you 
act like a lord, dictating what will happen and when, instead of working 
with people. I understand that this is a viable model (and often quite 
necessary) in many corporations, but it is not how the FSF generally does 
business, and I ask that you kindly recognize that and act in cooperation 
with others, instead of just dictatinig, which is what you're doing now. 
Just to clear up misconceptions, I have absolutely no problem with you 
personally nor with the idea of ObjC++. The last time you comitted a bunch 
of stuff, you broke the GNU ObjC runtime in your branch because you were 
(IMHO) careless, and I do not wish to see a repeat performance of that.

Cheers,
Alex Perez

Re: [objc-improvements-branch] About to start ObjC++

[Ziemowit Laski]

On 20 Jan, 2004, at 12.54, Alex Perez wrote:

> Pardon me, but are you completely blind to the discussions about
> greater openness that we've been having in here over the last several
> weeks, since this list has been started? You're being dictatorial as 
> ever,
> and I know I speak for others when I say that I don't like it one bit.

If you don't like ObjC++, you certainly don't have to use it! :-)  I 
honestly
don't know what your issue is here...

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Re: [objc-improvements-branch] About to start ObjC++

[Alex Perez]

Pardon me, but are you completely blind to the discussions about 
greater openness that we've been having in here over the last several 
weeks, since this list has been started? You're being dictatorial as ever, 
and I know I speak for others when I say that I don't like it one bit.

Good day,
Alex Perez

On Tue, 20 Jan 2004, Ziemowit Laski wrote:

> Hello,
> 
> This is just a friendly heads-up that the objc-improvements-branch,
> previously used to integrate Apple's ObjC fixes into the mainline,
> shall henceforth be used to develop the Objective-C++ front-end,
> to be integrated into mailine 3.5 upon completion.
> 
> Once objc-improvements-branch becomes even minimally usable, I'll
> send out another notice so that folks can try it out.
> 
> Thanks,
> 
> --Zem
> --------------------------------------------------------------
> Ziemowit Laski                 1 Infinite Loop, MS 301-2K
> Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
> Apple Computer, Inc.           +1.408.974.6229  Fax .5477
> 
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep
> 

[objc-improvements-branch] About to start ObjC++

[Ziemowit Laski]

Hello,

This is just a friendly heads-up that the objc-improvements-branch,
previously used to integrate Apple's ObjC fixes into the mainline,
shall henceforth be used to develop the Objective-C++ front-end,
to be integrated into mailine 3.5 upon completion.

Once objc-improvements-branch becomes even minimally usable, I'll
send out another notice so that folks can try it out.

Thanks,

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477