Per businesses intendo attivita’ commerciali, esse possono essere
negozio, ecommerce, edicola, ecc.
Alcune di queste classi condividono degli attributi pertanto ho creato
uno schema in cui la classe Business e’ la classe base e le altre
ereditano da Business.
Attributi Business:
name, state, description, notes
Attributi negozio < Business:
sq_meters, street_street_number
Attributi edicola < Business:
street, street_number
Attributi ecommerce < Business:
website
L’idea e’ creare Business come classe astratta con self_abstract_class
= true, per evitare Business.new, cosi’ facendo pero’ non posso
associargli nessun attributo.
Dal punto di vista logico l’idea mi sembra corretta ma dal punto di
vista pratico inattuabile.
In altri ambienti (Grails) l’utilizzo delle classi astratte funziona
esattamente come dovrebbe essere, e cioe’ e’ possibile associare degli
attributi che vengono ereditati dalle classi child ma non e’ possibile
create instanze della classe astratta.
Cosa mi suggerite?
Ero curioso.
un file di circa 13mb. Non un jpeg bensi uno zip che contiene un file
che si chiama anch’esso sss.jpg!
Anche il secondo sss.jpg uno zip! Lo zip contiene questo:
$ unzip sss.jpg.zip2
Archive: sss.jpg.zip2
inflating: SAS-Cheat.pdf
inflating: PC SAS Programs/BOF Test File TRM.sas
inflating: PC SAS Programs/Compare.sas
inflating: PC SAS Programs/MF to EXCEL.sas
inflating: PC SAS Programs/TRM DF Regression.sas
inflating: Base SAS.pdf
inflating: 243-29.pdf
inflating: SAS For Dummies 2nd Edition.pdf
inflating: SASCheat.pdf
Si tratta di documentazione sul linguaggio SAS:
Sembra un linguaggio con sintassi pessima pensato per usi specifici
(statistici, forse per banche).
Si tratta di documentazione sul linguaggio SAS: SAS language - Wikipedia
Sembra un linguaggio con sintassi pessima pensato per usi specifici
(statistici, forse per banche).
Confermo, ha una sintassi pessima e’ un software di statistica
pensato per gli ospedali, o almeno d me lo usano i biostatistici.
La sintassi è pessima ma non tiriamogli le pietre: è un linguaggio del
1966 ed è quello che si aspettavano gli informatici dell’epoca, assai
più pratici di Cobol e di Fortran che di Algol, il capostipite di buona
parte di quelli che usiamo oggi incluso il filone Simula (1967) ->
Smalltalk -> Ruby.
Vedremo se i nuovi linguaggi del 2043 (50 dopo Ruby) ci faranno dire che
Ruby è una schifezza