2017-10-26 10:20 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Oct 26, 2017, at 10:10 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Another question.
Will not these vectors deprecate Point in future ? Imaging that we will completely move to Bloc.
No. Point is a perfectly reasonable data structure to describe a position. A Vector is something else and has other contracts. The coincidence is that they share the same variables, but they have different API. For example, a vector has #length. A point does not.
Now Point implements most vector operations. The #length is defined as radius by #r message. I imaging that with new vector you will reimplement many of Point methods. Also I doubt that Point plays any role in system which is different than math vector.
And what about Rectangle? (Bloc implements own BlRectangle).
These two do not have the same semantics. BlRectangle is a BlGeometry and is used for defining a path within an element. BlRectangle is polymorphic with other paths such as BlEllipse or BlPolygon. Rectangle is a generic data structure that can be used for other purposes.
We should definitely try to find commonalities and opportunities for unification. However, we should not confuse state with types which are defined by the purpose they are used for (and associated behavior).
Doru
2017-10-26 9:26 GMT+02:00 phil@highoctane.be <phil@highoctane.be>: #(1 3 4 5 7 -2) asVector
Meh. Ugly.
{ 1. 3. 4. a. b } asVector
is the natural consequence.
v := (1,3,4,5,7,-2) asVector
keeps the parens. But why do I need to do that?
Autoformatting messing with my parentheses is just a mistake. I put them in, leave them where they are, 'kay? I do not need an editor that rewrites what I tell it. AST power or not.
And frankly, I like the "Feenk way of doing things" most of the time, so I am willing to go that route.
Phil
On Thu, Oct 26, 2017 at 8:52 AM, Peter Uhnák <i.uhnak@gmail.com> wrote:
Automatic formatting will turn it into
vector := 1,3,4,5,7,-2.
Which is not as nice.
And even though it looks ok for literal numbers (#(1 3 4 5 7 -2)
asVector would work too), this starts to look quite generic:
vector := width, height, depth.
Question: why not extend @ notation?
x @ y @ z?
Peter
On Thu, Oct 26, 2017 at 8:22 AM, phil@highoctane.be <
phil@highoctane.be> wrote:
I also like the , message for those vectors and the concatenation of
dimensions makes sense.
vector := (1,3,4,5,7,-2).
looks how it should be.
Readable, easy to translate vector stuff from reference text.
Phil
On Thu, Oct 26, 2017 at 7:00 AM, Nicolai Hess <nicolaihess@gmail.com>
wrote:
Am 25.10.2017 10:50 PM schrieb "Torsten Bergmann" <astares@gmx.de>:
Hi,
there might be reasons for an own 2D vector class (instead of using
Point).
But still I dislike the reimplementation of "," because for me so far it has the meaning of "concatenating things".
Like concatenating coordinates :-)
Here you redefine it to create vector instances and it works only up to three so far. Right?
I understand that this gives some similarities with the math notation (1,2) but I personally would prefer to use:
1@2 asVector
or Vector2D x: 1 y: 2
Thx T.
Gesendet: Mittwoch, 25. Oktober 2017 um 20:06 Uhr Von: "Tudor Girba" <tudor@tudorgirba.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] , for vector creation
Hi,
As mentioned in the separate thread, we played with introducing the extension:
, aNumber ^ BlVector2D x: self y: aNumber
This means that (10,20) will return a 2D vector.
We also have (10,20,30) which returns a 3D vector.
, is used for different meanings already in the image beside the collection concatenation. For example, in FileReference is adds a file extension. And Exceptions create a collection. In other packages, PetitParser uses it as a sequence operator.
Please voice your concerns.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Every thing should have the right to be different."
-- www.tudorgirba.com www.feenk.com
"When people care, great things can happen."