On Wed, Apr 3, 2013 at 11:08 PM, Logan Bell <[email protected]> wrote:
>> * Eliminate both the `private` visibility specifier and explicit `parcel`
>> visibility specifier.
>
> Does parcel imply any visibility level? In my mind I always thought of
> parcel as a package specifier.
Conceptually, the "parcel" is Clownfish's atomic unit of installation. The
meaning is roughly similar to `package` in Java and considerably more
restrictive than `package` in Perl. In terms of implementation, everything
assigned to a given parcel ends up in a single, consolidated DSO.
Right now, the `parcel` keyword can be used for two different purposes in a
.cfh Clownfish header file:
1. As part of a parcel affiliation (indicating that the contents of the file
belong to the specified parcel).
2. As a visibility qualifier indicating that a symbol is parcel-scoped.
The visibility qualifier usage of `parcel` is superflouous, because leaving a
symbol with unspecified visibility _also_ means parcel-scoped.
// Get_Num() is parcel-scoped, because that's the default.
int
Get_Num(Foo *foo);
// Get_Num() is still parcel-scoped -- adding the `parcel` keyword doesn't
// change anything.
parcel int
Get_Num(Foo *foo);
One of the changes I've proposed is removal of this superfluous usage of the
`parcel` keyword as a visibility qualifier, while keeping it as part of a
parcel affiliation.
>> * Eliminate the ability to specify visibility for object member
>> variables.
>
> Would all object member variables and methods be private by default?
* Object methods are parcel-scoped by default.
* Object member variables are private by default.
> Further, I believe this means that if we wanted these variables to be
> public they would be accessible via accessors?
Accessors, either parcel-scoped or public, can always be added to provide ways
for client code to get at the value of a member variable.
>> After the streamlining, classes, object methods, inert functions, and inert
>> variables would have two possible visibility levels:
>
> In the context clownfish what does the inert mean? Immutable?
"Not dynamic".
Clownfish symbols which are labeled with the `inert` qualifier have static
storage duration -- i.e., there is one fixed memory location at which the
symbol's value can be accessed, as opposed to there being multiple memory
locations on different object instances.
Static storage duration is also implied by the C keyword `static`. However,
`static` in C also indicates that a symbol has file-scoped visibility, while
`inert` in Clownfish defaults to parcel-scoped visibility and can be made
globally visible with the addition of the `public` visibility qualifier.
Early versions of Clownfish used the keyword `static`, but I thought it was
too confusing having `static` mean one scope in a .cfh Clownfish header file
and another scope in a .c implementation file -- so I made the call to use the
keyword `inert` instead.
Marvin Humphrey
