[#1711] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...>

Tanaka Akira:

22 messages 2003/11/19
[#1737] Re: open-uri patch, added progress_proc hook — Mathieu Bouchard <matju@...> 2003/11/23

[#1739] Re: open-uri patch, added progress_proc hook — Mathieu Bouchard <matju@...> 2003/11/23

[#1740] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...> 2003/11/23

On Sunday 23 November 2003 08:26 pm, Mathieu Bouchard wrote:

[#1741] Re: open-uri patch, added progress_proc hook — Mathieu Bouchard <matju@...> 2003/11/23

[#1718] Re: open-uri patch, added progress_proc hook — Elliott Hughes <ehughes@...>

22 messages 2003/11/21
[#1722] Re: open-uri patch, added progress_proc hook — Tanaka Akira <akr@...17n.org> 2003/11/22

In article <AD4480A509455343AEFACCC231BA850F17C434@ukexchange>,

[#1724] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...> 2003/11/22

On Saturday 22 November 2003 04:34 pm, Tanaka Akira wrote:

[#1726] Re: open-uri patch, added progress_proc hook — Tanaka Akira <akr@...17n.org> 2003/11/23

In article <200311221024.05642.transami@runbox.com>,

[#1731] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...> 2003/11/23

On Sunday 23 November 2003 02:24 am, Tanaka Akira wrote:

[#1732] Re: open-uri patch, added progress_proc hook — Tanaka Akira <akr@...17n.org> 2003/11/23

In article <200311230325.21687.transami@runbox.com>,

[#1733] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...> 2003/11/23

On Sunday 23 November 2003 03:10 pm, Tanaka Akira wrote:

[#1750] Re: open-uri patch, added progress_proc hook — Tanaka Akira <akr@...17n.org> 2003/11/24

In article <200311230648.41003.transami@runbox.com>,

[#1759] Re: open-uri patch, added progress_proc hook — Sean E Russell <ser@...> 2003/11/24

On Monday 24 November 2003 03:19, Tanaka Akira wrote:

[#1762] Re: open-uri patch, added progress_proc hook — "Nathaniel Talbott" <nathaniel@...> 2003/11/24

Sean E Russell [mailto:ser@germane-software.com] wrote:

[#1753] gc_sweep under 1.8 ... not syck.so — Richard Kilmer <rich@...>

We still encountered a gc_sweep in our use of Ruby 1.8 on Linux (v8).

16 messages 2003/11/24
[#1754] Re: gc_sweep under 1.8 ... not syck.so — ts <decoux@...> 2003/11/24

>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:

[#1757] Re: gc_sweep under 1.8 ... not syck.so — Richard Kilmer <rich@...> 2003/11/24

Yes, there are several (Ruby) threads working during this gc_sweep.

[#1758] Re: gc_sweep under 1.8 ... not syck.so — ts <decoux@...> 2003/11/24

>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:

[#1763] Re: gc_sweep under 1.8 ... not syck.so — Richard Kilmer <rich@...> 2003/11/24

of course this effects 300 machines ;-)

[#1755] Re: Controlled block variables — Jamis Buck <jgb3@...>

On Mon, 2003-11-24 at 02:04, T. Onoma wrote:

26 messages 2003/11/24
[#1756] Re: Controlled block variables — "T. Onoma" <transami@...> 2003/11/24

On Monday 24 November 2003 05:22 pm, Jamis Buck wrote:

[#1760] Re: Controlled block variables — Sean E Russell <ser@...> 2003/11/24

On Monday 24 November 2003 11:51, T. Onoma wrote:

[#1761] Re: Controlled block variables — "T. Onoma" <transami@...> 2003/11/24

On Monday 24 November 2003 06:40 pm, Sean E Russell wrote:

Re: Cascading class definitions effect objects

From: Mathieu Bouchard <matju@...>
Date: 2003-11-23 17:22:31 UTC
List: ruby-core #1736
On Sun, 23 Nov 2003, T. Onoma wrote:

> Analogous to the real world: when I make a cookie with a cookiecutter, all my 
> previous cookies do magically change because I later change my cookiecutter. 

If you want a suitable analogy for your real world: when you realize that
a cookiecutter can cut cookies, then you think of other cookiecutters as
able to cut cookies.

I think it's important to discern our models of the real world from what
the real world really is. It may be difficult, as we only do see the real
real world through our models of it.

In the real real world you don't have kitchen apparatus change behaviour
in magical ways, but our model of a certain object is can change our way
of conceiving it and using it.

I think that, in the blossoming of OO techniques, one very important reuse
that has been achieved is the reuse of common forms of human reasoning.
This is why OO may look more "natural" and "real world" than procedural
programming. But by "more natural" we mean "more human", and by "real
world" we mean the abilities to compartmentalize, to categorize, to
modularize, to interconnect, to abstract, to generalize, as we are used to
apply them in thinking about (and solving problems in) everyday life.

The programs that are written are very much part of reality, and it
doesn't matter how much nonphysical they are. What may make programs less
real is how as a shorthand we name objects in a program as if they were
the things out of the program that they represent. For example (to use an
overused example), if you name a student record class as StudentRecord,
then you are not virtualizing, but if you call it just Student, then you
are, in some way, playing make-believe that the Student is really in the
program. Of course no-one is _really_ mistaken, but still, some subtly
mistaken reasonings can arise, if analogies with the "real world" are
taken too far.

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju


In This Thread

Prev Next