| View previous topic :: View next topic |
| Author |
Message |
Tris Orendorff
Guest
|
 Posted: Wed Jan 12, 2005 3:50 am Post subject: Re: Avoiding the second historic mistake |
 |
|
tgm1024@hotmail.com wrote in news:1105301083.032364.246470@c13g2000cwb.googlegroups.com:
| Quote: | If H2O freezes and melts at the same temperature, how does it know
which to do?
|
It doesn't know which to do and that is why driving in the winter, up north here, is so dangerous. One has
to look out for icy water and watery ice because both are trouble.
--
Sincerely,
Tris Orendorff |
|
| |
|
 Back to top |
P.Hill
Guest
|
| Posted: Wed Jan 12, 2005 3:58 am Post subject: Re: Avoiding the second historic mistake (oh puleez) |
|
|
Dimitri Maziuk wrote:
| Quote: | There is no spoon.
|
That's too Zen for me! |
|
| |
|
| Back to top |
The Ghost In The Machine
Guest
|
| Posted: Wed Jan 12, 2005 4:01 am Post subject: Re: Avoiding the second historic mistake (oh puleez) |
|
|
In comp.lang.java.advocacy, Robert C Martin
<unclebob@objectmentor.com>
wrote
on Tue, 11 Jan 2005 13:50:49 -0600
<5gb8u0p8h0lbtnhpdg8s84rgmu4l2v7k2c@4ax.com>:
| Quote: | On Mon, 10 Jan 2005 22:01:33 GMT, The Ghost In The Machine
ewill@sirius.athghost7038suus.net> wrote:
In comp.lang.java.advocacy, Rod Davison
critsys@rogers.remove.com
wrote
on Mon, 10 Jan 2005 14:02:34 -0500
pan.2005.01.10.19.02.24.396627@rogers.remove.com>:
Overheard:
"Programming with C is like using a sharp knife with no handle. C++ has
made the knife much sharper. Java glued the knife in the sheath."
One wonders what C# did. :-)
Reinvented the knife, the sheath, and the glue.
|
Doncha mean "re-innovated"? :-)
[.sigsnip]
--
#191, ewill3@earthlink.net
It's still legal to go .sigless. |
|
| |
|
| Back to top |
dar7yl
Guest
|
| Posted: Wed Jan 12, 2005 5:40 am Post subject: Re: Avoiding the second historic mistake |
|
|
"Thomas G. Marshall" wrote:
| Quote: | Is it really possible that yet /another/ person didn't see this as the
joke
it was????????????
|
Sorry, if you want to use subtlety with me, you have to hit me upside the
head with a brick first:)
regards,
Dar7yl |
|
| |
|
| Back to top |
kurbylogic@hotmail.com
Guest
|
| Posted: Wed Jan 12, 2005 12:50 pm Post subject: Re: Static vs dynamic |
|
|
JTK wrote:
| Quote: | Phlip wrote:
The Ghost In The Machine wrote:
They /both/ suck!!
Ok, somebody clue me in here; what, precisely, are we discussing?
:-)
Use http://groups.google.com to survey this group and "static vs
dynamic".
Languages like Smalltalk and Ruby permit any foo.bar() call, if foo
is an
object with a bar. Languages like C++ and Java only permit the call
if foo
refers to an object of a class with a common base class containing
a virtual
'bar()' method.
That desn't even make sense Philip. C++ most certainly allows
"foo.bar()", whether bar() is declared virtual or not. Inheritance
or
lack therof doesn't matter. One of us is missing something here....
|
To me the advantage of the dynamic language is not how polymorphic
behavior is implemented but rather the ability to change a "types
definition" dynamically at runtime. With the addition of anonymous
methods to C# I could perhaps fake something simalar using hashtables
and anonymous methods.
LUA:
foo = {}
foo.bar = function() print("I was created at runtime!") end
foo.bar()
C#
class Program
{
delegate void method();
static void Main(string[] args)
{
IDictionary foo = new Hashtable();
//add methods to this object
foo["bar"] = new method(delegate()
{ Console.WriteLine("I was created at runtime!"); });
// call the method
((method)foo["bar"])();
}
}
Adding methods at runtime isn't possible with strongly typed classes.
So why on earth might we want to do this anyway? wouldn't a subclasses
and/or object wrappers work instead...?
Possibly not, perhaps for the same reason most Windows control classes
have a Tag property. The Tag property has absolutely no effect on the
control behavior at all its sole purpose is to allow the client to hang
additional properties such as to associate a recordId with items in a
listbox for example. Subclassing requires control of the creation
process. A wrapper might be added after creation however the wrapper
will have a completely different identity and thus unless you already
know what item it wraps or have a method to obtain an existing wrapper
its not very useful for adding properties as rewrapping it would just
create new instances of empty/default properties.
For example say listitems are inserted by listitem item =
listbox.add(partDescription); without the ability to add partId to the
item we may need to get more created such as using a hashtable to
associate the additional the partId with the item's index in the
listbox; partIds[item.Index] = partId and somehow try to ensure that
the map and listbox remain synchronized. In a dynamic language the
simplest solution may be to just add a partId property to the item at
runtime or better yet add the desired behavior item.DisplayDetails =
function() { partDialog.Show(partId); } and the item "type" now
includes a DisplayDetails() function as if perhaps it always had one.
- Kurt |
|
| |
|
| Back to top |
Food Fighter
Guest
|
| Posted: Thu Jul 31, 2008 9:47 am Post subject: Re: Why is Object Oriented so successfull |
|
|
The issue for the implementation of OO design and implementation practices
is fiurst of all, reusability of components. The second reason is that it
comes along as part of a methodology which incldes an OO programming
language, reusable components, modeling documentation of all portions of the
system which is to be part of the total system implementation. Ia m about 8
years behind so this is all new to me, and fresh on my mind. For the
winter, I am planning a lot of object design research. A booklist recently
invested in, is added in perpetuity ..
Sam's Teaching Yourself Database Program With Visual Basic 6 in 24HRS
Rahmel, Dan (USED, trade paper)
Web Database Developer's Guide with Visual Basic 5
Swank, Mark (USED, trade paper)
Object Oriented Databases Technology
Rao, Bindu R (USED, hardcover)
Object technology in application development
Tkach, Daniel (USED, trade paper)
Managing Your Move to Object Technology: Guidelines & Strategies for a
Mcgibbon, Barry (USED, trade paper)
Objects, Components, and Frameworks with UML: The Catalysis(sm) Approa
Dsouza, Desmond Fra (USED, trade paper)
An Introduction to Computing Using C++ and Object Technology
Ford, William (USED, softcvr w/comp
media)
Object Persistence: Beyond Object-Oriented Databases
Sessions, Roger (USED, hardcover)
"Daniel T." <daniel_t@earthlink.net> wrote in message
news:daniel_t-789169.21431012012008@earthlink.vsrv-sjc.supernews.net...
| Quote: | topmind <topmind@technologist.com> wrote:
Daniel T. wrote:
alexcpn <alexcpn@gmail.com> wrote:
Maybe I should frame the question more clearly- what is it so
special
in OO that makes it so successfully industrially. I really don't
'believe' that it is because of the way OO entity help us in closely
modeling real life etc
Here I must disagree. I think OO does help us to more closely model
the
real world.
Note that a good many OO proponents disagree that OO is mostly about
"modeling the real world". Bertrand Meyer, for example, dismisses the
idea that modeling the real world is the key point of OO. Further, the
real world sometimes is not the ideal approach. We wouldn't want to
model a physical card catalog in a library, for example. We have
technology that transcends 3D card cabinets. Why be stuck in the 3D
world when a virtual world (indexing) can have gazillion dimensions?
That sort of "modeling the real world" is a fantastic example what I
called "the simple terms expressed in some beginner books."
When I say that, I don't mean in the simple terms expressed in some
beginner books (the silly "Nouns are classes" approach.) Rather, I
mean
in the way an OO system is structured. Well designed OO systems are
less
centralized than previous approaches.
Some quotes:
What do we find in our day-to-day lives...? We find many machines,
which interact with each other in a very decentralized fashion.
There
is no central control mechanism... Structured methods are built on
the idea of centralized control... If decentralization allows the
real world... to operate, shouldn't we attempt to handle complex
software problems in the same way? (Riel 1996)
or
Plants consist of three major structures (roots, stems, and
leaves),
and each of these has its own structure... the parts of a plant
form
a hierarchy, and each level of this hierarchy embodies its own
complexity.
All parts at the same level of abstraction interact in well-defined
ways....
There are always clear boundaries between the outside and the
inside
of a given level. For example, we can state that the parts of a
leaf
work together to provide the functionality of the leaf as a whole,
and yet have little or no direct interaction with the elementary
parts of the roots. In simpler terms, there is a clear separation
of
concerns among the parts at different levels of abstraction. (Booch
1994)
Yet to extrapolate this to the business domain has been nearly
impossible. This is because in the real world thing are often
interrelated and this interrelatedness is what gives it its power.
Nested wrapping can only be taken so far and runs out of steam very
quickly as you scale.
Life proves you wrong. Nested levels of abstraction scales very well
indeed. I agree that OO isn't for all domains. I'll take your word for
it that the kind of business apps you write are one of them. If all you
are doing is selecting and presenting information, then OO is probably
way more than you need. |
|
|
| |
|
| Back to top |
topmind
Guest
|
| Posted: Thu Jul 31, 2008 4:39 pm Post subject: Re: Why is Object Oriented so successfull |
|
|
On Jul 30, 9:47 pm, "Food Fighter" <chefofspaghe...@yahoo.com> wrote:
| Quote: | The issue for the implementation of OO design and implementation practices
is fiurst of all, reusability of components. The second reason is that it
comes along as part of a methodology which incldes an OO programming
language, reusable components, modeling documentation of all portions of the
system which is to be part of the total system implementation. Ia m about 8
years behind so this is all new to me, and fresh on my mind. For the
winter, I am planning a lot of object design research. A booklist recently
invested in, is added in perpetuity ..
Sam's Teaching Yourself Database Program With Visual Basic 6 in 24HRS
Rahmel, Dan (USED, trade paper)
Web Database Developer's Guide with Visual Basic 5
Swank, Mark (USED, trade paper)
Object Oriented Databases Technology
Rao, Bindu R (USED, hardcover)
Object technology in application development
Tkach, Daniel (USED, trade paper)
Managing Your Move to Object Technology: Guidelines & Strategies for a
Mcgibbon, Barry (USED, trade paper)
Objects, Components, and Frameworks with UML: The Catalysis(sm) Approa
Dsouza, Desmond Fra (USED, trade paper)
An Introduction to Computing Using C++ and Object Technology
Ford, William (USED, softcvr w/comp
media)
Object Persistence: Beyond Object-Oriented Databases
Sessions, Roger (USED, hardcover)
"Daniel T." <danie...@earthlink.net> wrote in message
news:daniel_t-789169.21431012012008@earthlink.vsrv-sjc.supernews.net...
topmind <topm...@technologist.com> wrote:
Daniel T. wrote:
alexcpn <alex...@gmail.com> wrote:
Maybe I should frame the question more clearly- what is it so
special
in OO that makes it so successfully industrially. I really don't
'believe' that it is because of the way OO entity help us in closely
modeling real life etc
Here I must disagree. I think OO does help us to more closely model
the
real world.
Note that a good many OO proponents disagree that OO is mostly about
"modeling the real world". Bertrand Meyer, for example, dismisses the
idea that modeling the real world is the key point of OO. Further, the
real world sometimes is not the ideal approach. We wouldn't want to
model a physical card catalog in a library, for example. We have
technology that transcends 3D card cabinets. Why be stuck in the 3D
world when a virtual world (indexing) can have gazillion dimensions?
That sort of "modeling the real world" is a fantastic example what I
called "the simple terms expressed in some beginner books."
When I say that, I don't mean in the simple terms expressed in some
beginner books (the silly "Nouns are classes" approach.) Rather, I
mean
in the way an OO system is structured. Well designed OO systems are
less
centralized than previous approaches.
Some quotes:
What do we find in our day-to-day lives...? We find many machines,
which interact with each other in a very decentralized fashion.
There
is no central control mechanism... Structured methods are built on
the idea of centralized control... If decentralization allows the
real world... to operate, shouldn't we attempt to handle complex
software problems in the same way? (Riel 1996)
or
Plants consist of three major structures (roots, stems, and
leaves),
and each of these has its own structure... the parts of a plant
form
a hierarchy, and each level of this hierarchy embodies its own
complexity.
All parts at the same level of abstraction interact in well-defined
ways....
There are always clear boundaries between the outside and the
inside
of a given level. For example, we can state that the parts of a
leaf
work together to provide the functionality of the leaf as a whole,
and yet have little or no direct interaction with the elementary
parts of the roots. In simpler terms, there is a clear separation
of
concerns among the parts at different levels of abstraction. (Booch
1994)
Yet to extrapolate this to the business domain has been nearly
impossible. This is because in the real world thing are often
interrelated and this interrelatedness is what gives it its power.
Nested wrapping can only be taken so far and runs out of steam very
quickly as you scale.
Life proves you wrong. Nested levels of abstraction scales very well
indeed. I agree that OO isn't for all domains. I'll take your word for
it that the kind of business apps you write are one of them. If all you
are doing is selecting and presenting information, then OO is probably
way more than you need.
|
I disagree that OOP makes better reuse, and it appears to be falling
out of favor as a main selling point of OOP among OO proponents.
And "nested levels of complexity" only goes so far for applications
that need multiple viewpoints where the "key abstraction" is different
depending on who is using it and what they need. "Levels" fail there.
There are also lateral abstractions. An account's view of car parts
and an engineer's view of car parts will usually be different, but one
is not "higher" than another.
Trees have been overused in software engineering and its time to
rethink this.
It's a decent solution to covering up bare-bones hardware, but tends
not to scale beyond that. Too many OO books focus on covering up low-
level hardware that they don't give very representative examples for
those not writing embedded apps or systems software.
Rather than only reading books, I challenge you to stretch you mind by
also showing how OOP would improve the following example:
http://www.geocities.com/tablizer/payroll2.htm
-T- |
|
| |
|
| Back to top |
Phlip
Guest
|
| Posted: Sat Aug 02, 2008 1:13 am Post subject: Re: Why is Object Oriented so successfull |
|
|
Food Fighter wrote:
| Quote: | The issue for the implementation of OO design and implementation practices
is first of all, reusability of components.
|
That's the common verbiage, but it misleads. A design can be DRY, with good
design patterns that leverage virtual methods, yet it might not be plug-and-play
reusable.
The good news is all the objects within a design should correctly re-use each
other. That would show they are decoupled, and can change independently. New
code will probably re-use old methods.
The "reuse" verbiage is essentially marketing to your boss: You can go faster by
reusing more things. That's true when done right, but you still gotta manage
expectations, and work a little harder to get the reuse. OO makes that easier
than Brand X by helping the reused code to decouple from the reusing code.
| Quote: | The second reason is that it
comes along as part of a methodology which incldes an OO programming
language, reusable components, modeling documentation of all portions of the
system which is to be part of the total system implementation.
|
And unit tests. They tend to use components via narrow scenarios, so they help
force them to be reusable.
| Quote: | Ia m about 8
years behind so this is all new to me, and fresh on my mind. For the
winter, I am planning a lot of object design research. A booklist recently
invested in, is added in perpetuity ..
|
Gotta try /Design Patterns/ and /Refactoring/.
| Quote: | Sam's Teaching Yourself Database Program With Visual Basic 6 in 24HRS
Rahmel, Dan (USED, trade paper)
|
EEEK!
--
Phlip |
|
| |
|
| Back to top |
Food Fighter
Guest
|
| Posted: Mon Aug 04, 2008 5:44 pm Post subject: Re: Why is Object Not! |
|
|
Component testing is part of the physical implementation, beyond the OO
issues. Yet, another important OO issue is that it is meant to enhance the
performance of a team of developers. So, in tht way it may suit a certain
breadth relating to a project dimension, and life cycle. When acquiring
employment, you may have to take on some new design methods as suited to the
legacy and documents of an existing company system. And sofar as a new
problem definition, it is a leap to assume OO is to be used. They perform a
preliminary system analysis to check on the costs and other parameters
..i.e., OO literature, and practices, before making the OO assertion in the
design arena.
Port 23 is bogus
"Phlip" <phlip2005@gmail.com> wrote in message
news:d9Kkk.6138$np7.1584@flpi149.ffdc.sbc.com...
| Quote: | Food Fighter wrote:
The issue for the implementation of OO design and implementation
practices
is first of all, reusability of components.
That's the common verbiage, but it misleads. A design can be DRY, with
good
design patterns that leverage virtual methods, yet it might not be
plug-and-play
reusable.
The good news is all the objects within a design should correctly re-use
each
other. That would show they are decoupled, and can change independently.
New
code will probably re-use old methods.
The "reuse" verbiage is essentially marketing to your boss: You can go
faster by
reusing more things. That's true when done right, but you still gotta
manage
expectations, and work a little harder to get the reuse. OO makes that
easier
than Brand X by helping the reused code to decouple from the reusing code.
The second reason is that it
comes along as part of a methodology which incldes an OO programming
language, reusable components, modeling documentation of all portions of
the
system which is to be part of the total system implementation.
And unit tests. They tend to use components via narrow scenarios, so they
help
force them to be reusable.
Ia m about 8
years behind so this is all new to me, and fresh on my mind. For the
winter, I am planning a lot of object design research. A booklist
recently
invested in, is added in perpetuity ..
Gotta try /Design Patterns/ and /Refactoring/.
Sam's Teaching Yourself Database Program With Visual Basic 6 in 24HRS
Rahmel, Dan (USED, trade paper)
EEEK!
--
Phlip |
|
|
| |
|
| Back to top |
dlzc
Guest
|
| Posted: Thu Oct 23, 2008 4:08 am Post subject: Re: Free SoftWare, free antiviruses, free internet soft, fre |
|
|
On Oct 22, 8:11 pm, FLORA <freewar...@yahoo.com> wrote:
.... Free trojans (and not the condoms) ... |
|
| |
|
| Back to top |
yuyo217@gmail.com
Guest
|
| Posted: Thu Oct 23, 2008 5:44 am Post subject: Re: Free SoftWare, free antiviruses, free internet soft, fre |
|
|
On Oct 23, 11:11 am, FLORA <freewar...@yahoo.com> wrote:
| Quote: | http://freesoftware11.blogspot.com
|
Free trojans (and not the condoms) ... Free trojans (and not the
condoms) ... Free trojans (and not the condoms) ... Free trojans (and
not the condoms) ... Free trojans (and not the condoms) ... Free
trojans (and not the condoms) ... Free trojans (and not the
condoms) ... Free trojans (and not the condoms) ... Free trojans (and
not the condoms) ... Free trojans (and not the condoms) ... |
|
| |
|
| Back to top |
Jorma
Guest
|
| Posted: Mon Nov 17, 2008 3:41 am Post subject: Suomi ei ole demokratia vaan plutokraattinen diktatuuri |
|
|
Kun Nikolai Tesla about 20-luvulla kehitteli elämänsä tärkeintä keksintöään,
eli arkista loistevaloaan USA:n käyttöön hän tuotatti markkinoille ns.
"kylmäkatodiloisteputken".
Jonka peruspiirre on toimia kuten mm. neonvalo, eli
suoraläpisyöttösytytyksellä. Laitteessa siis EI odes ole sytytintä
lainkaan!***
En tarkoin tiedä miten laajalti maailmalla tämä tekniikka on käytössä, mutta
maassiivisesti jo n. vuosisadan. Ilmeisesti systeemi sitoutettiin sikäläisen
110v ja 60Hz kantaverkkon tarpeisiin. Kätevä laite kaikkineen kyllä. Mutta
vaatii elohopeahöyryionisaatiot sisälleen myös ja tosiaan myös loisteaineet. |
|
| |
|
| Back to top |
Jaakko Heiskanen
Guest
|
| Posted: Mon Dec 01, 2008 5:49 am Post subject: Re: Mitä eroa on kakella ja Kakella - Osa II |
|
|
Fingridistä ydinupottaja.
07.06.2008 oli näemmä turhaa etsiä edes lehdistä päivää aiemmin julkaistua
ilouutista energiamarkkinoiltamme. Jotain todella outoa
tiedotussensuuripakoa Suomen ydinhallinnoltamme taas. Ja koska muut
tiedoitusvälineet jälleen näistä uskalla rivin riviä julkaista nin toki
kaikki jää taas ydintutusti niille jotka osaa ja uskaltaa, silvuplee arvon
lukijani.
Jos katsomme sähkölaskujamme huomaamme miten itse sähkön hinta on tuskin
samaa luokkaa kuin massiivinen yhtä suuri osuus sähkön siirtokustannusten
kanssa. Kun EU määräsi Fingrigin sähkönsiirtobisneksestä poistettavaksi
Fortumin, TVO:n ja tämänkaltaiset pelkästään niinikää energiantuotantoyhtiöt
oli se enemmän kuin shokki ydinalamme rahoituksille. Mikään nimittäin tässä
sähköbisneksessä ei ole niin tuottavaa kuin siirtoverkkofirmamojen loputon
ja takuuvarmistettu rahantulo siirtomaksuineen ilman kilpailupeikkoja.
Ydinyhtiöt mm. Fortum ovat omistamalla sähköverkkomonopoleja kyenneet
käyttämään ilmaiseksi omaa sähköverkko-osuuttaan laistaakseen kilpailevia
energiafirmoista täysin poiketen huikeita ydinsiirtosähkömonopolilaskuja.
Vielä kuppaamaan muilta sähköyhtiöiltä rahat pois!
Kyseessä on EU.n tulkinnan mukaan härskein mahdollinen
markkinavääristysmekaniikka myös ydinyhtiömonopoleillemme. Ja siksi niiden
markkinamääräävyydestä lyödään kerralla päätä poikki, tässä ja nyt! Eli
jatkossa se míkä lihottaa ydinyhtiöitämme Fortumeja ja muita muutetaan
plusalkumerkistä miinusmerkkiseksi valtaisaksi menon loiseräksi. Kuvaavaa
tilanteelle on se, että uutista ja sen taustoja ei maassamme lehtiyhtiöt
uskalla lainkaan julkaista, ei juuri edes muut. Mutta Fortumi mainittiin ja
mm. TVO jos mikä on nimenomaan EU:n mainitsema PELKKÄ energiantuotantoyhtiö
jos mikä! Joten maamme ydinyhtiöt saa niin rankasti jopa EU:lta lunta
tupaan, että kenties kovasti enteellisesti TVO:n johtajaportaasta alkoi
asian julkitulosta ankarankova rotaatiopakohyllytystä jo perjantaista 06.06.
Elämme todella mielenkiintoisia aikoja ja näyttää ydinvaltiomonopoleilla
olevan enemmän kuin hikistä jatkotaivalta ankarasti tiedossa. Ehkä tosiaan
alkaa päivä paistamaan ja asiallisuus lyömään väkisin ydinmonopolejamme
härskeine ydinaikeineen ahtaalle!) |
|
| |
|
| Back to top |
Leo Peters
Guest
|
| Posted: Sat Dec 13, 2008 12:26 am Post subject: Plagiointia! |
|
|
Olen jopa itse hämmästynyt siitä peittelemättömästä ydinalan panikoinnista,
jota jo parhaillaan päällemme kaatuvat ydinekotuhot täällä netissä
aiheuttaa. Oli tosiaan täys ylläri miten SELKEÄSTI ydinlobbaajat lopulta
alkoivat oivaltaa ydinalan syyksi nykymaailmamme jyrääviin tuhoihin.
Mehiläistuhon massiivisuus näyttää olevan kulminaatiopiste. Eli vielä viime
vuona tänne oli aika harvat kirjoittamassa, että ydinala tulee jatkossa
tappamaan kaiki maailmamme mehiläispopulaatiot. Toki silloin asiasta
kirjoittelin. Mutta tajuavia oli prosenteissa. Nyt kun päivästä toiseen käy
JUURI kuten olen esittänyt on jotain aniharvaa ydinpoliisia lukuunottamatta
alkanut faktat upota. Jopa mehiläiskasvattajaliiton sain viimein tajuamaan,
että ydintaposta on kyse. Aiemat ydinalan disinfot vaikenivat muutamissa
päivissä. Hienoa, että reaali alkaa kinostamaan ja lyömään massoina läpi
viime vuona vielä totaalivaikenevaan lehdistöömme myös. Ilmeisesti 90%
mehiläiskato ja sitä seuraava 1/3 osan ruokakato alkaa näkyä niin kiistatta.
Ilmeisesti ydinhallintomme on menettämässä peliä koko laajuudella luonnon
tuhoamisensa tiellä. Koska TABU:ja on laajasti nyt lisää:
A/Maailmanlaajuinen ilmoitettu niin sammakkoeläinten, kuin matelijoiden
kuoleminen niinikää maailmanlaajuisesti ydinpäästöjen
tritiumsadelammikkoihin on kylmästi määrätty vaiettavaksi 100%! Aika härski
aihe, kuin sentään kansainvälisesti todettiin faktaksi toki!
B/Maailman kaikki tunnetut havumetsät tulevat kuolemaan muutamissa
lähivuosissa. Japanista, Portugalista ja Siperiasta vääjäämättä 90%
metsistämme lähivuosina tappavista millisistä mäntyankeroisista on tehty
löydöksiä peräti 40kertaa. Vain hetki enää ja ydinteollisuuden säöhkölle ei
jatkossa ole lainkaan puuta! Tarkoin on vaiettu, että Venäjän puukauppa
takkuaa sikäläisistä megametsätuholähteistä jo. Aihe on SELKEÄSTI 60v
käyttöharhoilleen suunnitelluille ydinlaitoksillemme suoraa kuolemaa! Mega
TABU! Ilman muuta.
C/Kaspian kampamaneetit ajoivat Merentutkimuslaitoksen meriämme
kartoittamasta härskimmän päälle ei edes kalastajia ulkomerillemme sallita
raportoimaan maneetti-invaasioita. Kyseessä kun on se keskeisin
kulminaatiopiste, jonka TVO:n ydinlauhdekumpuamiset tuottaa megatuhona.
Raportointiin pestataan nyt silkkana sikailuna amatöörijoukkoa muka
tutkimaan leviä vaan. Ydinhallintomme törkyilee aiheessa niin, ettei mitään
rajaa. Kampamaneettien tiedetään jo kautta maailman tukkineeen voimaloiden
massiivivesikanavistot kuin korkki pullot. Ruotsissa tilanne on jo
sellainen, että ydinvoimaloissaan on 80% pysyvät varotehonalenemat.
Pian -50%. Tai kuten Venäjällä merilauhteesta ydinalalla on PAKKO luopua,
koskei meren valtaisat jopa 7 800eläintä/m2 kokoiset tulevat
kampamaneettikannat takaa enää ikinä asiallista jäähdytettä ydinvoimaloille.
Mega-TABU
aiheena myös.
D/ Niin tämä mehiläiskato johtuu tunnetusti ydinionisaation aiheuttamasta
ionosfäärimuutoksen suunnistusharhauttamisesta. Joka siis eksyttää muuten
terveet mehiläiset pois muutoksillaan pois tutuilta pesänsä paluureiteiltä.
Tästä tabusta alkaa asiis puhti olemaan ydinalaltamme poissa, kun KAIKKI
huomaa miten kato etenee. Aiemmin tekaistut virusvalheet eivät uppoa
kansaan. Koska jopa mehiläiskasvattajat huomaavat, että suunistuksen ongelma
ja ydinvoimalan läheisyys ratkaisee suoraan mehiläisten hävikin! Siksi
massoittain TVO:n lähistöltä pelastetaan mehiläispesiä turvaan
ydinsaasteilta Itä-Suomeen. Jotkut yksinkertaiset ydinlobbarit erehtyy
luulemaan näin hetkeksi kasvaneista paikallismehiläispopuloista, että kaiki
ikäänkuin olisi kohdallaan, kuten enneen. Ei toki!(
E/ Ruotsissa on kaikien aikojen rajuimmat metsäpalot 02.06.2008. Koko
Etelä-Suomessa metsäpalovaroitus. Tippaa ei vettä olla tuttuun tyyliin saatu
oikeastaan sitten lumien. Kuka oikeasti yllättyi, että jo viime vuona
viimein jopa EU:ssa myönnetty -40% ydinaavikoituminen etenee varmasti
tappaen yhä hurjemmin. Kuka enää edes muistaa, miten mm. Portugali paloi
kokonaan superkuivuuksiinsa. Tilanne jatkuu ja pahenee. Ranskassa myös jo
viime kesänä metsää kuivettui enemmän kuin säteilyllä pilattu ydinaavikkomaa
kasvoi. Tämä vuosi on taas edellistä pahempi. Vielä koettaa toki
Ilmatieteenlaitos vedättää hiilidioksidilisääntymisen synnytämine +30%
sadantakasvuharhoineen. Pelkkä vilkaisu jo ennen varsinaista kesää kuolevaan
ja kuivettuvaan luontoomme kertoo disinfon ydinalan panikoinniksi.
Virannomaistemme luotettavuus lähenee syystä nollaa. Ydinala tappaa ja
takuuvarmasti niin kauan, kunnest tuhoaa vähintään itsensä, kenties
säteilypäästöineen koko ihmiselon mahdollisuudet myös. Ja mikä oleelista
ydinalamme TARKOIN tietää mitä ydinkauhuja saamme jatkoon nähdä säteilyjen
kiristäessä elämisen mahdollisuuksia hetki hetki, hetkeltä kaikkialta
ympäriltämme!(( ((
PS. Kuten olemme huomanneet lehtien sivut yht äkkiä täyttyvät
virannomaisuhkailuista siitä, ettei nettiin saa jatkossa enää kirjoittaa
edes näistä mitä ympärillämme tapahtuu? Tajuaako kansamme miksi? Koska
ydinhallintomme tietää, että jatkossa kyyti käy niin hirveäksi tulevine
ydinpäästöjen punasadekausineen, ettei siitä saa antaa edes
silminnäkijälausuntoja enää! Tajjuatteko, homma on täysin poissa ydinalamme
hallinnasta. Einsteinin varotukset alkavat saamaan lihaa rajusti luittensa
ympärille. Yksi on tulevassa varma ydinala vetelee syyllisinä viimeisiään! |
|
| |
|
| Back to top |
Daniel T.
Guest
|
| Posted: Sun Jan 04, 2009 12:14 am Post subject: Re: Design question regarding inheritance/polymorphism |
|
|
Angus <anguscomber@gmail.com> wrote:
| Quote: | I have designed a framework for working with devices. There is a
framework which has a generic device class - called devices. To
interface with an actual device the framework user would extend
devices like this:
class ABCDevice : public devices
Generally the program created will connect to a specific XYZ and there
will be many devices connected ot this XYZ. XYZ is not a device. Hope
that makes some sense.
The problem I am trying to get my head round is that it is useful to
retain a collection of devices. But if devices has been extended then
a collection of <Whatever>devices is required.
So do I just not bother with this functionality in the framework and
let the user of the framework write all the collection of devices
code? Or is there some way to write some of this code?
If I have a collection of devices (currently a list of device* 's),
then this is not so useful if framework user has extended devices. My
framework has no knowledge of all the possible different types of
specific device created.
Do I need some osrt of AddDevice() function - but then what to pass?
Any suggestions/help with my confusion would be much appreciated.
|
I think this would better be asked in comp.object.
That said, the mere fact that you have a Device class implies that you
have device users, and things that all device users have in common
should probably be expressed as a class. The only question remains is
should device users inherit from this class or should they contain one...
--
Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away.
-- Antoine de Saint-Exupery |
|
| |
|
| Back to top |
|
