Welcome Guest Search | Active Topics | Members | Log In

Interfejsy - zaczątek dokumentacji Options · View
habela
Posted: Thursday, March 24, 2005 9:01:27 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
W nawiązaniu do nadesłanego przez Michała dokumentu opisującego SBQL dla Odry, postanowiłem w podobnej (znacznie bardziej zwięzłej niż w papierach) formie opisać propozycję w zakresie interfejsów.
Dokument dostępny na: http://www.pjwstk.edu.pl/~habela/Odra/interfaces.html
Dokument jest mocno roboczy - w szczególności - nie jest zgrany co do składni z zaimplementowanymi już elementami języka. No i w przeciwieństwie do większości dokumentacji - opisuje dopiero to, co (być może) dopiero będzie implementowane.
Kilka uwag do bieżącej wersji dokumentu:
- forsuję tu proponowane w artykułach umieszczenie operacji insert - zgrabniej pasuje tu do definicji interfejsów.
- nie uwzględniłem jeszcze wirtualnych pointerów (będę tu jeszcze miał ważne pytanie - wkrótce w osobnym wątku).
- nie jest rozstrzygnięta sprawa tablice<->sekwencje (używam tu tylko jednej notacji - z nawiasami kwadratowymi - podobnie w stylu jak UML - uzupełniona o słowo kluczowe ordered).
- specyficzny sposób traktowania modułów - swego czasu nie wzbudził istotnych kontrowersji, ale jednak trzeba uzgodnić.
- nie wprowadzono na razie pseudo-konstruktora dla perspektyw (wyobrażam sobie, że pasowałaby tutaj operacja generyczna w stylu on_insert_new czy po prostu on_new) - sprawa do doprecyzowania.
- nie opisano sposobów tworzenia i zarządzania schematami użytkownika.
- sposób nakreślenia sygnatury operacji - obecnie dość przypadkowy - też wymaga weryfikacji.

Postać tekstu dość surowa - HTML bez styli. (Potwierdzam, że format mocno niewygodny.)
stencel
Posted: Friday, March 25, 2005 11:55:52 AM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Mam drobne prosby do redakcji artykulu.

1. Kod niech bedzie napisany w znacznikach <pre> </pre> Wtedy naprawde latwiej jest pisac. W szczegolnosci w ostatnim przykladzie sekcji "Generalization hierarchy..." linia zaczynajaca sie od "class" zlewa sie z poprzednia linia.

2. W sekcji "Derived data definitions" akapit z virtual keyword; powinien byc chyba czescia nastepujacego po nim elementu <ul>...</ul>, bo tak to nie bardzo jest jasne o co chodzi.

Merytorycznie to zastanawia mnie sformulowanie "Moreover the referenced type is required to describe complex object". Czy to nie uraga relatywizmowi obiektow? W ksiazce Szef pisze, ze jesli nie ma sensownych niezmiennikow to nie ma co dla kazdego obiektu powolywac klasy. Czy chcemy z tego zrezygnowac?

Aha, Twoj tekst jest dosc klarowny i chyba nadaje sie jaka baza artykulu na ER...
habela
Posted: Friday, March 25, 2005 12:47:32 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
stencel wrote:
1. Kod niech bedzie napisany w znacznikach <pre> </pre> Wtedy naprawde latwiej jest pisac. W szczegolnosci w ostatnim przykladzie sekcji "Generalization hierarchy..." linia zaczynajaca sie od "class" zlewa sie z poprzednia linia.
2. W sekcji "Derived data definitions" akapit z virtual keyword; powinien byc chyba czescia nastepujacego po nim elementu <ul>...</ul>, bo tak to nie bardzo jest jasne o co chodzi.

Słusznie - właśnie poprawiam i wkrótce wystawię.
stencel wrote:
Merytorycznie to zastanawia mnie sformulowanie "Moreover the referenced type is required to describe complex object". Czy to nie uraga relatywizmowi obiektow? W ksiazce Szef pisze, ze jesli nie ma sensownych niezmiennikow to nie ma co dla kazdego obiektu powolywac klasy. Czy chcemy z tego zrezygnowac?

W tym konkretnym zdaniu (nieco je teraz zmieniłem) chciałem zaznaczyć, że przewidujemy możliwość rozpinania asocjacji (nawet jednokierunkowych) wyłącznie pomiędzy obiektami złożonymi.
Problem chyba raczej po stronie terminologii. Niezależnie, czy nazwiemy to klasą czy typem, to nawet dla tych obiektów złożonych, które nie potrzebują żadnych metod można stwierdzić, że ich niezmiennikiem będzie ich dopuszczalna budowa. Tu zaś po prostu potrzebuję poinformować, do jakiego typu obiektu będzie prowadziła asocjacja (i wobec tego - czego w tym obiekcie użytkownik powinien się spodziewać). Z tego punktu widzenia interesuje nas interfejs obiektu docelowego, czyli albo przypisany mu nazwany interfejs (definicja export) albo bazowy interfejs jego klasy (definicja export zagnieżdżona w klasie).
stencel wrote:
Aha, Twoj tekst jest dosc klarowny i chyba nadaje sie jaka baza artykulu na ER...

Dzięki. A co do artykułu na ER, to pracuję nad problemem, ale nie potrafię powiedzieć, czy zdążę coś rozsądnego zaproponować. (Bo niezbyt mi się widzi taki "atak klonów" akurat w wypadku ER...). Trochę kombinowałem jeszcze z problemem wirtualnych wskaźników oraz ról w kontekście perspektyw. Sądzę, że dotknięcie któregoś z tych problemów byłoby niezbędne na okrasę tekstu na ER...
Dzisiaj podeślę moje pytania dotyczące (jakby już zamkniętej) dyskusji o wirtualnych wskaźnikach.
habela
Posted: Sunday, April 17, 2005 9:26:58 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Poprawiona edycja (zakres merytoryczny na razie prawie bez zmian): http://www.pjwstk.edu.pl/~habela/Odra/interfaces02.html
Nie wklejałem do dokumentacji wiki (BTW: dostępna z zewnątrz pod adresem http://odra.pjwstk.edu.pl/wiki/index.php/Strona_główna), bo dotyczy propozycji rozwiązania, nie zaś zaimplementowanej funkcjonalności.
Wkrótce (po jakiejś konkluzji obecnej dyskusji) - uzupełnię o zagadnienia wirtualnych pointerów oraz wirtualnych ról.
stencel
Posted: Wednesday, April 20, 2005 3:30:13 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Do dokumentu "Interface definitions (v. 0.2)".

Mam problem z przykladem zaczynajacym sie od "module Samples".

Po pierwsze, warto napisac w dokumencie interfejs Contact (i moze skomentowac), zeby bylo wiadomo jaki jest wzajemny stosunek interfejsu Contact z exportem, ktory nastepuje w nastepnej linii.

Po drugie, jesli chodzi o ten podkreslnik, to znacznie lepszym pomyslem byloby chyba dodanie jakiego operatora, np. typeOf i wtedy:

Code:
new( c : typeOf(contact) ) {


Albo nawet:

Code:
new( c : Contact ) { // z duzej litery == interfejs, czemu nie?


Users browsing this topic
Guest


Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Main Forum RSS : RSS

Powered by Yet Another Forum.net version 1.9.1.6 (NET v2.0) - 11/14/2007
Copyright © 2003-2006 Yet Another Forum.net. All rights reserved.
This page was generated in 0.167 seconds.