Mailing-List: contact dev-help@lucy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucy.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <515D536C.6010206@aevum.de>
Date: Thu, 04 Apr 2013 12:18:20 +0200
From: Nick Wellnhofer <wellnhofer@aevum.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: dev@lucy.apache.org
References: 
 <CAAS6=7jku=KA1vxZ3mGxuWFAfuGNaBjPS5UreLdXjDjJbm19fw@mail.gmail.com>
In-Reply-To: 
 <CAAS6=7jku=KA1vxZ3mGxuWFAfuGNaBjPS5UreLdXjDjJbm19fw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [lucy-dev] Symbol visibility refinements

On 03/04/2013 01:10, Marvin Humphrey wrote:
> Therefore, I'd like to propose a couple refinements to rationalize symbol
> visibility in Clownfish.
>
> *   Eliminate both the `private` visibility specifier and explicit `parcel`
>      visibility specifier.
> *   Eliminate the ability to specify visibility for object member variables.
>
> After the streamlining, classes, object methods, inert functions, and inert
> variables would have two possible visibility levels:
>
> *   `public`, meaning visible from outside the DSO.
> *   unspecified, meaning DSO-scoped (or parcel-scoped -- same thing)

+1 since I don't see a way to enforce other visibility specifiers anyway.

Nick