ooRexx Operating System Analog Classes
The basic premise for these classes is to provide a standardized class
hierarchy to the
operating system environment from generic behaviour to platform specific
behaviour.
The will allow for the logical extension of the class hierarchy
I, for one, do not think this is a good idea. You are using a
starting point of the operating system, which is a mistake in my
opinion. The better starting point should be from the standpoint of
the function you wish to provide, define the operations that class
should provide and implement it in
While I agree to a certain extent, I believe it breaks down quickly when
you get
into specific OS functionality differences. Lets take file meta data as
an example.
*nix operating systems provide a host of meta data information that is
not available
on Windows. Like file creation date,
FYI: I probably won't have Internet access for the next couple of
weeks, so if you don't see any posts from me that is why.
On Fri, May 7, 2010 at 8:22 AM, Rick McGuire object.r...@gmail.com wrote:
I, for one, do not think this is a good idea. You are using a
starting point of the operating
On Fri, May 7, 2010 at 11:46 AM, David Ashley
david.ashley@gmail.com wrote:
While I agree to a certain extent, I believe it breaks down quickly when
you get
into specific OS functionality differences. Lets take file meta data as
an example.
*nix operating systems provide a host of meta
Really the same response I already gave David. Although, I might add,
there should be a application of the 80/20 rule here too. We have
some many areas where portable function is lacking that I think our
focus areas should be first on creating portable extensions and then
filling in the platform
Rick -
You have expressed my idea perfectly. But what I want to do is to
formalize the structure of the heirarchy for all such instances. Just
adding a new subclass for some specific feature or set of features
invites the creation of a whole slew of libraries, some built one way
and other
I guess my problem is that you seem intent on always forcing this to
be a hierarchy. That doesn't always make sense. For example, and
UnixFileSystem class could provide all of the additional function you
might need without needing to be part of a hierarchy...any more than
ooDialog need be
Not true, There is functionality on some systems no available on others.
Extended attributes is a perfect example. It is unavailable on AIX but
available on most other *nix platforms. So you could not put it into a
generic *nix class. AIX has a lot of differences between other *nix
variants
On Fri, May 7, 2010 at 12:36 PM, David Ashley
david.ashley@gmail.com wrote:
Not true, There is functionality on some systems no available on others.
Extended attributes is a perfect example. It is unavailable on AIX but
available on most other *nix platforms. So you could not put it into a
We are not really disagreeing with each other :-)
I only want to formalize how the hieararchy should be constructed when
extending it is necessary. By documenting and formalizing the structure
we make it easy to understand and extend as necessary. That way when a
new platform comes along we
On further reflection, one of the things that might make this whole
thing easier is if the ::method and ::routine directives could define
the same method name multiple times in a class. Then use an operating
system keyword to determine which method is used. Something along the
line of
For me, the biggest impediment to the adoption of ooRexx on *nix
platforms is the lack of direct access to the low-level functions. Perl
programmers have had access to the low level functions since the
beginning. When I try to convert a Perl or PHP porgrammer to ooRexx the
first questions are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
interesting discussion. I think we can all agree, that the smallest
common denominator of all functionality is sometimes not enough, there
are functions that are helpful or required which would not be available
in this case.
Still, we have to
All -
This is just a proposal and could change in form in a major way over
time. Concrete is nowhere to be found in this proposal.
After giving the RexxUtil discussion more thought, I believe I have the
outline of a solution that will take us forward into the future. I
propose that we develop
On Thu, May 6, 2010 at 12:25 PM, David Ashley
david.ashley@gmail.com wrote:
All -
This is just a proposal and could change in form in a major way over
time. Concrete is nowhere to be found in this proposal.
After giving the RexxUtil discussion more thought, I believe I have the
outline
On Thu, May 6, 2010 at 9:25 AM, David Ashley david.ashley@gmail.com wrote:
After giving the RexxUtil discussion more thought, I believe I have the
outline of a solution that will take us forward into the future. I
propose that we develop a set of classes that encapsulate operating
system
The real problem with generic classes is that there are functions that
exist in an OS that just do not have an analog in other operating
systems. As an example, take printing.
Printing on Windows has OS specific APIs. Thus you can create a nice
wrapper class for the printing subsystem. *nix
On Thu, May 6, 2010 at 12:54 PM, David Ashley
david.ashley@gmail.com wrote:
The real problem with generic classes is that there are functions that
exist in an OS that just do not have an analog in other operating
systems. As an example, take printing.
Yeah I see what you are saying David.
19 matches
Mail list logo
