Questions about external objects

> Good points. I've uploaded new versions to The Inbox:
>
> Installer squeakInbox
> package: 'System-ul.688';
> package: 'Sound-ul.41';
> package: 'Network-ul.155';
> package: 'Files-ul.141';
> install.
>
> The new class is called ExternalObjectTable. ExternalSemaphoreTable is gone. All API is in SmalltalkImage in a separate category named external objects.
>
>
> Levente
>
> On Mon, 27 Oct 2014, Bert Freudenberg wrote:
>
>> On 26.10.2014, at 14:38, Levente Uzonyi <[hidden email]> wrote:
>>
>>> On Sun, 26 Oct 2014, Bert Freudenberg wrote:
>>>
>>>> Yes, the implementation itself looks good.
>>>>
>>>> It's just a bit unfortunate that the user code gets even less generic than it was before.
>>>
>>> What do you mean by "less generic"? Is it that the code says ExternalSemaphoreTable instead of Smalltalk?
>>
>> Yes.
>>
>>> The code was extracted from Smalltalk more than 14 years ago, because
>>>
>>> "It seemed cleaner to deligate the reponsibility here versus adding more code and another class variable to SystemDictionary"
>>
>> Delegating is cleaner indeed. You took out the delegation and made user code not use the Smalltalk facade anymore, but instead use the implementation directly.
>>
>> This delegates to ExternalSemaphoreTable (or anywhere else):
>>
>> Smalltalk unregisterExternalObject: semaphore
>>
>> This exposes ExternalSemaphoreTable:
>>
>> ExternalSemaphoreTable unregisterExternalObject: semaphore
>>
>> E.g., you already mentioned that "ExternalSemaphoreTable" is misnamed since it can store any object. Why spread the use of it everywhere then? If we rename it to "ExternalObjectsTable" later then we are breaking the API and have to change all senders. Much simpler to change the delegation methods.
>>
>>> I could have left all (indirect) users of the ExternalSemaphoreTable unchanged, but I think we really should make SmalltalkImage less monolithic and remove those "proxy" methods from it in the near future.
>>
>> I see nothing wrong with Smalltalk being a single facade for system services that have no obviously good home elsewhere.
>>
>>> The new methods give additional performance boost (because we know that the Semaphores are new, so we don't have to check if they are already included, and because we don't have to wait for the lock multiple times, when multiple Semaphores are registered or unregistered) especially for Sockets, which was the main reason I spent so much time on this.
>>
>> I would be surprised if the indirection itself has any real performance impact, and it's simple to add optimizing methods to the facade, too.
>>
>> I had suggested putting the API in Semaphore itself (maybe on the class side) but since it's not specific to Semaphores I agree it's better to put elsewhere.
>>
>> - Bert -
>>
>>
>>
>>
>