This is a repost to the gnu.gnustep.discuss newsgroup, because gnu.org is
dropping my mailing list postings on the floor with an Invalid address in
message header error.
Alex Perez wrote:
Richard Frith-Macdonald wrote:
[snip]
So, for each class/method, we need to know which version of
On 2005-05-08 22:14:51 +0100 Alex Perez [EMAIL PROTECTED] wrote:
So what do you advocate for the parts of the API which were introduced
after OpenStep, but before MacOS-X, and the parts of the API which were in
OpenStep but were removed before MacOS-X was released?
It should be obvious, but I
Alex Perez wrote:
I think whether or not a class was introduced in OPENSTEP 4.0, 4.1, or
4.2, at this point, is completely irrelevant, and I personally am not
going to research this. Besides, we work off the OpenStep specification,
not anything else, when it comes to the original API
I think we are agreed that we want to categorise a method/class by
the version where it was introduced, and the version where it was
removed (NeXT/Apple have removed some things from their APIs)
This sounds like a good plan.
Just to be clear, deprecation does NOT count as removal, right?
I
On 2005-05-08 14:17:27 +0100 Adrian Robert [EMAIL PROTECTED] wrote:
I think we are agreed that we want to categorise a method/class by
the version where it was introduced, and the version where it was
removed (NeXT/Apple have removed some things from their APIs)
This sounds like a good plan.
Just
Richard Frith-Macdonald wrote:
On 2005-05-07 08:59:45 +0100 Alex Perez [EMAIL PROTECTED]
wrote:
Sheldon, Richard, Adam, et. al:
Alex Perez wrote:
Sheldon Gill wrote:
I'd be very happy to create a write up for you and help/mentor the
process. I may be able to assist with a few tools as well.
Richard Frith-Macdonald wrote:
On 2005-05-08 14:17:27 +0100 Adrian Robert [EMAIL PROTECTED] wrote:
I think we are agreed that we want to categorise a method/class by
the version where it was introduced, and the version where it was
removed (NeXT/Apple have removed some things from their APIs)
Adrian Robert wrote:
I think we are agreed that we want to categorise a method/class by
the version where it was introduced, and the version where it was
removed (NeXT/Apple have removed some things from their APIs)
This sounds like a good plan.
Just to be clear, deprecation does NOT count as
Richard Frith-Macdonald wrote:
On 2005-05-08 19:26:12 +0100 Alex Perez [EMAIL PROTECTED]
wrote:
However, for simplification, we can treat the opriginal OpenStep spec
as MacOS-X version 0.0 and the NeXT releases of the OPENSTEP system
as being versions 4.0, 4.1, 4.2 (can't remember if OPENSTEP
On 2005-05-08 19:32:28 +0100 Alex Perez [EMAIL PROTECTED] wrote:
I'm not sure about OPENSTEP versions, but we certainly discriminate
between
OpenStep (the specification, which we certainly do have online
documentation for) and later APIs. There are certainly a few APIs that
were added/removed
On 2005-05-03 03:09:02 +0100 Sheldon Gill [EMAIL PROTECTED] wrote:
Richard Frith-Macdonald wrote:
Secondly, I'd like the docs to clearly state the source for
functions/methods as OpenStep, MacOS (differentiate puma, jaguar, panther
and tiger) or GS (version).
The current documentation does that
Richard Frith-Macdonald wrote:
Secondly, I'd like the docs to clearly state the source for
functions/methods as OpenStep, MacOS (differentiate puma, jaguar,
panther and tiger) or GS (version).
The current documentation does that for Openstep/MacOS/GNUstep ... so
extending the mechanism to
Fine. We're mostly agreed. I'm just really against single letter
identifiers for the non-mathematical case. Always. That was really the
point that I was making, even if I wasn't so clear about it.
Single letter identifiers can make sense for the non-mathematical case.
I think on this there
Richard Frith-Macdonald wrote:
So your recommendation is
static NSString *
BundleObjectName(NSString *path, NSString* executable)
over
static NSString *
bundle_object_name(NSString *path, NSString* executable)
in this module private case?
Actually, my recommendation is to not force people to a
--- Richard Frith-Macdonald [EMAIL PROTECTED]
wrote:
On 2005-04-30 08:05:03 +0100 Sheldon Gill
[EMAIL PROTECTED] wrote:
Secondly, I'd like the docs to clearly state the
source for
functions/methods
as OpenStep, MacOS (differentiate puma, jaguar,
panther and tiger) or GS
On 2005-04-30 08:04:57 +0100 Sheldon Gill [EMAIL PROTECTED] wrote:
Richard Frith-Macdonald wrote:
Functions, though, are much more ambiguous:
The NeXT standard is GSFunction() pretty much everywhere.
The GNU standard is gnu_function().
Both are followed internally in different places.
I try to
Richard Frith-Macdonald wrote:
Functions, though, are much more ambiguous:
The NeXT standard is GSFunction() pretty much everywhere.
The GNU standard is gnu_function().
Both are followed internally in different places.
I try to stick to the GSFunction() style everywhere, and reserve the
On 2005-04-24 05:49:37 +0100 Sheldon Gill [EMAIL PROTECTED] wrote:
There are a couple of naming standards in use. The trouble is that standard
GNU form conflicts with standard NeXT and Apple forms.
For ObjC methods the standard is verbClause or typeInitialiser.
For ObjC classes the standard is
Richard Frith-Macdonald wrote:
On 2005-04-24 05:49:37 +0100 Sheldon Gill [EMAIL PROTECTED] wrote:
FWIW... I believe that better specification of coding standards is a
good thing. I don't have strong feelings either way for most of the
issues mentioned. But I think we would get a lot more
--- Sheldon Gill [EMAIL PROTECTED] wrote:
There are some things which don't seem clear from the coding standards.
This has lead to things being done differently in various places. I
think it is a good idea to clean up and standardise.
Hence, I'm proposing a number of
I think we should also be clear that dictionary or dict is preferred
over d. Except for mathematical function implementations single or
double character identifiers are a bad idea.
Ahm ... yes, single or double character identifiers are very difficult to
search/replace, and are generally
On 2005-04-24 05:49:37 +0100 Sheldon Gill [EMAIL PROTECTED] wrote:
There are some things which don't seem clear from the coding standards.
This has lead to things being done differently in various places. I think
it
is a good idea to clean up and standardise.
Hence, I'm proposing a number of
On Apr 23, 2005, at 10:49 PM, Sheldon Gill wrote:
Naming
==
There are a couple of naming standards in use. The trouble is that
standard GNU form conflicts with standard NeXT and Apple forms.
Sure, that all sounds fine.
Documentation commenting
==
Where should gsdoc
Hello,
On Sunday, April 24, 2005, at 06:49 AM, Sheldon Gill wrote:
There are some things which don't seem clear from the coding standards.
there always are,
The NeXT standard is GSFunction() pretty much everywhere.
The GNU standard is gnu_function().
Both are followed internally in different
On 24/04/05, Sheldon Gill [EMAIL PROTECTED] wrote:
Are there other coding standard issues which should be addressed?
Two suggestions:
1. Remove the (dangerous) use of
if ([obj boolMethod] == YES)
replacing it by
if ([obj boolMethod])
2. All method calls made through an
IMP ahould have a
On Apr 24, 2005, at 12:49 AM, Sheldon Gill wrote:
There are some things which don't seem clear from the coding standards.
This has lead to things being done differently in various places. I
think it is a good idea to clean up and standardise.
Hence, I'm proposing a number of
There are some things which don't seem clear from the coding standards.
This has lead to things being done differently in various places. I
think it is a good idea to clean up and standardise.
Hence, I'm proposing a number of additions/clarifications with the aim
to make things clear and
27 matches
Mail list logo
