🚀 go-pugleaf

"Marcin Grzębski" <mgrzebski@taxussi.no.com.spam.pl> wrote in message 
news:dka85j$mnh$1@nemesis.news.tpi.pl...
> Jaroslaw Kowalski wrote:
>> Ciekawi mnie po co w ogóle MS pozostawił w dotnecie takie nieobiektowe 
>> pojęcie jak publiczne pola.
>
> Co jest w tym nieobiektowego?
> Przepraszam bardzo ale takiej definicji obiektowości nie znam.

Jedną z podstawowych cech obiektowości jest (wybierz właściwe słowo):

1. encapsulation
2. hermetyzacja
3. enkapsulacja
4. kapsułkowanie (pozdrowienia dla p. JMD)
5. ...
6. ...
7. ...

Udostępnienie publicznego pola, po którym każdy z zewnątrz może pisać bez 
kontroli jest zaprzeczeniem tej idei.

>> Wystarczyło zabronić ich stosowania i w każdym przypadku generować 
>> automatycznie właściwość z ukrytym polem prywatnym przechowującym stan.
>
> No, to byłby naprawdę wynalazek na miarę "systemu totalitarnego
> programowania". Czy naprawdę tak ciężko jest samemu napisać
> kod właściwości?
> Dlaczego odbierać komuś możliwość korzystania z pól publicznych?

Ależ skąd. Chodzi raczej o generowanie automatyczne właściwości 
opakowujących te pola. W .NET masz rozróżnienie na pola i właściwości, gdzie 
raczej jest zgoda że w publicznych interfejsach należy używać właściwości. 
Gdyby wszystkie pola publiczne były przez kompilator tłumaczone jako 
właściwości (Property) a nie pola (Field) to zniknąłby problem 
kompatybilności binarnej.

>> JITter dość dobrze radzi sobie z inline'owaniem takich konstrukcji jak 
>> trywialne get/set więc chyba nie powinno być problemu wydajnościowego. 
>> Zachowana zostałaby za to binarna kompatybilność kodu w przypadku 
>> zdefiniowania własnej operacji get/set w przyszłości.
>
> Oczywiście wszystko da się zrobić. Ale jak to się ma do
> przejrzystości kodu i składni samego języka?

Mówię tylko o tym, że dla uniknięcia Field'ów w interfejsie publicznym 
kompilator mógłby tłumaczyć:

--------
public int Counter;
--------

każdorazowo na

--------
private int _Counter;
public int Counter
{
    get { return _Counter; }
    set { _Counter = value; }
}
--------

public readonly typ nazwa; byłoby tłumaczone jako właściwość z akcesorem(?) 
get a pola prywatne zostałyby po staremu.

> Osobiście jestem przeciwnikiem tego co M$ zrobił ze składnią
> właściwości o różnych modyfikatorach dostępu, czyli:
>
> public int IntValue {
> get {
> // ...
> }
> protected set {
> // ... }
> }

A ja jestem za. W Soodzie bardzo chętnie bym powitał takie usprawnienie już 
w .NET 1.1. Chodzi głównie o możliwość ustawienia "set" jako "internal". 
Czyli biblioteka/assembly/pakiet kodu sama może zmodyfikować jakąś 
właściwość a klienci mogą tylko ją czytać. Obecnie muszę robić SetXXX() do 
ustawiania i int XXX { get; } do pobierania.

Jarek