Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

You could use the pointer/raw memory API to implement that. One reason why I dislike the idea of introducing fixed-size arrays as a first-class language feature is that it adds an additional construct with quite niche use. Non-type generic parameters instead give you a powerful tool that you c

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

> A few things immediately spring to mind: > • Fixed-size arrays > • An optimized Matrix type > • Swifty syntax for Fourier transforms > • A numerical integrator (or diff-eq solver!) > • BigInt capabilities > > The first of these (fixed-size arrays) will probably require compiler support. Fixed

Re: [swift-evolution] End of source-breaking changes for Swift 3

> On 29 Jul 2016, at 00:21, Saagar Jha via swift-evolution > wrote: > > The reason C-style for loops were removed were because most of the time they > could be represented by Swift syntax. Have you taken a look at > stride(from:to:by:)? A minor correction: it should be ‚all of the time‘ :) I

Re: [swift-evolution] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

Great news! Given that this was probably the most polarising proposal ever, I am very impressed with the patience and professionalism the core team has shown in handling the situation and ultimately converging on an elegant solution — all that under oppressive deadline! A barrel of whiskey would

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

> On 22 Jul 2016, at 12:11, L. Mihalkovic wrote: > > > > Regards > (From mobile) > > On Jul 22, 2016, at 9:22 AM, Taras Zakharko via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> To be honest, I have difficulty with the termin

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

To be honest, I have difficulty with the terminology here. Why use the term ‚metatype‘ in the first place? Why not just ‚Type'? Or ‚TypeDescriptor‘ (in analogy to ObjectIdentifier)? What do we actually gain by the technical distinction between a type and a type of a type? I would understand it i

Re: [swift-evolution] Extending declaration scope to condition for `repeat { } while ()`

This is definitively something very useful but it also introduces a strong asymmetry into Swift statements. In all control-flow statements, the condition is part of the outer scope. Or, to be more precise, its part of an intermediate scope between the outer and the inner scope (as you can declar

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

> On 18 Jul 2016, at 18:31, Xiaodi Wu wrote: > > At the same time, your solution results in a lot of unnecessary boilerplate. > > It's an exaggeration to say that it's *a lot* of boilerplate. It's one line > or two in the base class. > Sure, it might be rare with methods, but don’t forget ab

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

> On 18 Jul 2016, at 14:07, Károly Lőrentey via swift-evolution > wrote: > > > I see no drawback to this pattern; it is quite clear and simple. Therefore, > in the interest of keeping the language free of needless complexity, I > suggest we change the proposal to remove the implicit "sealed"

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution > wrote: > > I agree with Kevin Ballard on being open by default for methods/ properties > http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ > >

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

> * What is your evaluation of the proposal? +1. Looks much better than the previous version and makes a lot of sense to me. A quick clarification question (I didn’t find any mention of this in the proposal, but I might have missed it): what happens if a class is declared open, but does

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

I have deliberately kept away from the discussion on this topic, as I didn’t feel like I can contribute in any meaningful way. In all honesty, I have barely used ‚traditional’ OOP paradigms in the last few years at all. While OOP is a useful tool and its great for modelling certain relationship

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

Great! This cleanly separates between the type and the name/signature! Simple and consistent. Thank you! A clarification question: do i understand correctly that steps 2 and 3 will not be included in Swift 3 due time constraints? — T > On 14 Jul 2016, at 06:47, Chris Lattner via swift-evolut

Re: [swift-evolution] [Review] SE-0121: Remove `Optional` Comparison Operators

> * What is your evaluation of the proposal? +1. Fully support this change. ‚Optional' comparison operators hide the fact that the value is boxes which can lead to confusing behavior and difficult to find bugs. Personally, I always unbox my optionals before doing any kind of comparisons.

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

There is some truth in every joke ;) I do like goto though. It makes my C code cleaner and easier to maintain. But given that Swift already has a very reasonable restricted goto mechanism with labels, I am as happy as it gets :) — T > On 12 Jul 2016, at 18:21, Douglas Gregor wrote: > > >> O

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

I’d love to see goto in Swift, but on the other hand, do {} with labels have so far been sufficient for any practical problem I encountered so far. Goto is much more useful in languages like C, which lack nested functions and other abstraction mechanisms. Of course, I wouldn’t try to write a h

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

There is possible impact on existing code: a switch statement inside a loop, that contains a continue. — Taras > On 11 Jul 2016, at 04:27, Erica Sadun via swift-evolution > wrote: > > A quick pitch to introduce `continue` to switch statements. This would be > additive and could not be consi

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> On 09 Jul 2016, at 15:25, Goffredo Marocchi wrote: > > > Sent from my iPhone > > On 9 Jul 2016, at 11:31, Taras Zakharko > wrote: > >> Well, now that function type and function signature are officially separate >> things, > > I think we may have made a mista

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

Well, now that function type and function signature are officially separate things, we need means to treat them as separate things. In particular, we need a way to force signatures on closure parameters (and maybe on some variables) while leaving function variables generally signature-agnostic.

Re: [swift-evolution] [Review] SE-0118: Closure Parameter Names and Labels

> * What is your evaluation of the proposal? In general +1, except maybe the change of to isOrderedBefore: by: in sort-related functions. I fear that the new label makes it less clear that the ordering relation is that of strict precedence. It can be particularly confusing for people used

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

I always wrap my case blocks in curly braces. Personally, I agree with G.B. that the switch syntax seems inconsistent at best. While there are labels and limited form of goto in Swift, case labels don’t act anything like that. I’d prefer symmetry with if by having obligatory braces. — Taras

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

The designers of Swift have adopted a pragmatic approach to things: get a language that can be useful practically quickly, then improve it as things go. Its very Apple-like and I think it makes a lot of sense. We have a lot of useful changes in Swift 3.0, but the language is still far from compl

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

I would also be interested in a clarification on this point from Chris or someone else from the core team. The accepted proposal states that labels are illegal in function types (that is also what I was arguing for towards the end of the review discussion) but at the same time Cris mentions t

Re: [swift-evolution] Bit arrays

> On 04 Jul 2016, at 00:44, Chris Lattner via swift-evolution > wrote: > > >> On Jul 3, 2016, at 2:42 PM, Daryle Walker via swift-evolution >> wrote: >> >> Since objects aren't addressable by default, there wouldn't be the problems >> with a bit-packed Boolean collection that C++'s "vector

Re: [swift-evolution] Random ideas: goto, loop, multiple dispatch, explicit aliasing

Swift already has a very useful goto operator that avoids the usual problems associated with arbitrary control flow. With labels and continue/break you can implement very complex control flow schemas, but still maintain structured code. I have used it at multiple occasions and this is something

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> > The goal of the review process is to improve the proposal under review > through constructive criticism and contribute to the direction of Swift. When > writing your review, here are some questions you might want to answer in your > review: > > * What is your evaluation of the propos

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

od idea. Natural languages are really not a good source of inspiration in this regard. Best, Taras > On 01 Jul 2016, at 05:33, Jordan Rose wrote: > >> >> On Jun 30, 2016, at 13:36, Taras Zakharko via swift-evolution >> mailto:swift-evolution@swift.org>> wrote

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

IMO, this is the most mathematically meaningful and semantically transparent solution. Floor and ceiling might be the popular terms but roundedUp/Down is much cleaner. > On 25 Jun 2016, at 20:55, Haravikk via swift-evolution > wrote: > > >> On 25 Jun 2016, at 11:06, Karl via swift-evolutio

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

amateur — don’t feel in my plate discussing this here. I believe that > there currently might be some inconsistencies in the language design that > should be sealed with (but maybe they are no inconsistencies at all and I > simply have false expectations). > > Best, > >

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

eve that there currently might be some inconsistencies in the language design that should be sealed with (but maybe they are no inconsistencies at all and I simply have false expectations). Best, Taras > > On Thu, Jun 30, 2016 at 12:42 PM, Taras Zakharko via swift-evolution >

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

> * What is your evaluation of the proposal? +1 > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes > * Does this proposal fit well with the feel and direction of Swift? Yes > * If you have used other languages or libraries with

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On 30 Jun 2016, at 21:20, Xiaodi Wu wrote: > > On Thu, Jun 30, 2016 at 2:14 PM, Taras Zakharko via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > > On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution > > mailto:swift-evolution@swift

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0111: Remove type system significance of function argument > labels" begins now and runs through July 4. The proposal is available here: > > > https://github.com/app

Re: [swift-evolution] [Review] SE-0109: Remove the Boolean protocol

ote: > > >> On Jun 29, 2016, at 5:48 AM, Taras Zakharko via swift-evolution >> wrote: >> >> Just a quick clarification: I was under impression that the utility of >> Boolean was that one could extend any type to behave as a boolean type and >> thus b

Re: [swift-evolution] [Review] SE-0109: Remove the Boolean protocol

> On 29 Jun 2016, at 15:47, Matthew Johnson via swift-evolution > wrote: > > > IIRC Optional conformed to this protocol early on and that conformance was > removed. In practice the idea of a protocol for "truthiness" to which > non-Boolean types conform caused more confusion than it provide

Re: [swift-evolution] [Review] SE-0109: Remove the Boolean protocol

Just a quick clarification: I was under impression that the utility of Boolean was that one could extend any type to behave as a boolean type and thus be used in control flow constructions etc. Not something that has to do often, but nice to have nevertheless. I would be sad if this functionalit

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

> On 09 Jun 2016, at 18:53, Ethan Eberle via swift-evolution > wrote: > > That said, the one process improvement I have is that proposals should > ideally only be “Accepted” by the core team as it is originally written (or > with relatively minor changes) or completely “Rejected”. The “Accep

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

A concern that I have with this is that comma seems to get inconsistent treatment in the language. In conditionals, commas clearly represent conjunctive clauses. However, the core team has also argued (review of SE-0095) that usage of comma implies disjunction and proposes that ‚&‘ is used for

Re: [swift-evolution] Add conversion String -> Bool

IMO, that is too idiosyncratic to be a standard language feature. You should extend Bool based on the specific needs of your application. Thats what the extensions are for. Best, t. > On 04 Jun 2016, at 15:10, Arsen Gasparyan via swift-evolution > wrote: > > Hello, > > It would be grea

Re: [swift-evolution] [Returned for Revision] SE-0095: Replace protocol syntax with Any

I never had any problems with commas, as I always read them as conjunctive clauses, but I understand that an explicit conjunction may be less confusing. Personally, I’d prefer if there was no special syntax (aka Any<>) for existential types, whether generalised or not. I fail to see a principal

Re: [swift-evolution] Enhanced existential types proposal discussion

This looks very nice! Two questions/comments 1. I would prefer to write simpler existential types without Any, e.g.: let a: Sequence where Sequence.Iterator.Element == Int Is there a reason why we need Any<> at all, aside as a parsing aid? 2. If this proposal gets accepted, does it m

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

When I need a loop with complex control flow that does not fit into the classical while {} or repeat {} while structure, I use this: do_stuff: do { … continue do_stuff } This pattern explicit and allows very complex control flow patterns without the drawbacks of the unrestricted goto const

Re: [swift-evolution] [Draft] Expanded min/max algorithms

Hi Nate, I think this is a very useful addition! I also had a related proposal few days ago: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014665.html I feel like min/max extensio

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

+1 Makes language cleaner and more consistent. > On 15 Apr 2016, at 06:57, Chris Lattner via swift-evolution > wrote: > > We currently accept function type syntax without parentheses, like: > > Int -> Float > String -> () > > etc. The original rationale aligned with the fact that we wante

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

True, that makes sense. I was simply trying to explore different possibilities of how these things could be represented in the syntax. What about #type(d) for static (declaration) type and type(v) for dynamic (value/instance) type? Or would that be potentially confusing as well? The reason why

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

I do not think that I was conflating these two aspects. Using #type(self) would return the particular type of the current instance (dynamic type) while using #type(A.var) would return the declared (static) type of the property. Now, let a = A() #type(a.var) would again return the actual (

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

I do not understand why we can’t do type(self) or even #type(self) Personally, I find .Self business to be quite confusing and idiosyncratic. Having a generic #type() directive would be a general improvement for the language design and it would also open up future possibilities such as e

Re: [swift-evolution] What about a VBA style with Statement?

Because many APIs use configuration/partial initialisation patterns. Look at Metal for example. But I agree that most of the time, its not such a big deal. — Taras > On 13 Apr 2016, at 17:34, Kurt Werle wrote: > > I've always thought that the with construct is not a good idea. It seems to

Re: [swift-evolution] What about a VBA style with Statement?

We had this kind of proposal earlier, didn’t seem to be very well received. I still think it would be a useful thing, but I’d do it as a statement (extension of do) that introduces new lexical scope (similar to self) — Taras > On 13 Apr 2016, at 16:25, Sean Heber via swift-evolution > wrote:

Re: [swift-evolution] [Proposal] Add .order() family of methods to Collection

Hi, I think it depends on how expensive the indexed access is on the collection. I use it primarily on arrays, where self[i] essentially boils down to a pointer dereference, so I expect the generated code to be very efficient. Your version might be faster for collection with expensive element

Re: [swift-evolution] [Proposal] Safer half-open range operator

I do not think that this should be included in the default library as it is inconsistent with the behavior we generally have on collections (where user is responsible for correct indexing). However, it is quite trivial to define a new subscript operation, e.g. subscript(safe: Range) — Taras >

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> * What is your evaluation of the proposal? +1. I think it makes the collection model more simple and more flexible at the same time. By coupling index to a specific collection, rather then treating it as a separate, independent entity, we can more easily implement alternative collection

Re: [swift-evolution] [Proposal] Allow optional binding of instance variables in constructors

roblem that these variables can be accessed from outside. This is why I am suggesting to restrict guard to constructors only and fail the object construction if the guard fails. — Taras > > Jacob > > On Mon, Apr 11, 2016 at 12:31 AM, Taras Zakharko via swift-evolution > mailto:

[swift-evolution] [Proposal] Add .order() family of methods to Collection

Swift standard library already offers a useful set of sort() functions. However, it is also often useful to know how the collection should be rearranged in order to become sorted. For example, R defines the order() function which returns a permutation of collection indexes which rearrange the c

[swift-evolution] [Proposal] Allow optional binding of instance variables in constructors

One place where I find myself using the guard statement a lot is state initialisation. E.g. in init() guard let device = MTLCreateSystemDefaultDevice(), library = device.newDefaultLibrary() else { fatalError(“Could not initiallize Metal, aborting”) } Here, the two var

Re: [swift-evolution] [Proposal] Factory Initializers

At first, I was opposed to this idea but after working with many heterogeneous implementations of the same protocol, where instance creation needs to be dynamically dispatched to based on the properties of the data, I think that factory initialisers might be a nice idea. However, it would IMO ma

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I am agnostic on a .striding() method, but I am strongly agains any suggestions of removing/replacing the global stride() function. The stride function does not pollute the global namespace as it is a universally useful construct (among others, for implementing classical iterating for loops), ha

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

replaceWith* is also my favourite here (same for *InPlace). Sure, it might be verbose, but the semantics is very clear and seems apply to a wide range of relevant situations. In the end, there are hundreds if not more messages in this (and related) threads and i am sure that you guys spent even

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

A big +1 to this notation. > On 06 Apr 2016, at 20:47, Milos Rankovic via swift-evolution > wrote: > > >> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> func anyCommonElements(lhs: T, _ rhs: U) -> Bool >> where T : SequenceT

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

How would this work with OptionSetType? It also uses leading dot prefixes for initialisers, but implementations are usually structs. If I understand correctly, leading dot can be used in any case where the type can be inferred by the compiler. Changing the rules for enums seems strange to me.

Re: [swift-evolution] [Suggestion] Case-based dispatch for enum methods

the lines of ‘missing implementation for func() for case A, B, C' > > TJ > > On Tue, Apr 5, 2016 at 1:57 AM, Taras Zakharko via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Is the lack of comments due to general disinterest in such a thing or did my >

Re: [swift-evolution] [Suggestion] Case-based dispatch for enum methods

Is the lack of comments due to general disinterest in such a thing or did my mail go amiss somehow? ;) Best, Taras > On 31 Mar 2016, at 14:39, Taras Zakharko wrote: > > Recently, I have been working on implementing some non-trivial data > structures in Swift (its about storing polygons in

Re: [swift-evolution] [Proposal] Custom operators

I think this is a great suggestion! One potential problem I can see (if I understood this correctly) is that modules are allowed to set up their own precedence rules for operators defined elsewhere. I think this might lead to some difficult to debug errors if a developer of one module (who is us

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

Hi John, there seems to be a fundamental misunderstanding on your part how collection based (for .. in..) loops operate. The enumerable sets you talk about do not need to be created upfront - they can be virtual/lazy (however you want to describe them). So yes, the Swift for … in .. loop has

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

This is what happens if you don’t follow the swift-evolution list for a while… I have send a very similar suggestion to the list today (but mine focuses more on methods). Didn’t mean to plagiarise your idea, sorry! Maybe we should bring the two of them together. Best, Taras > On 23 Mar 201

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

> On 31 Mar 2016, at 14:12, Ted F.A. van Gaalen wrote: > > Alas, I don’t understand you irritation, > but it is your irritation, not mine. Well, its quite simple: we are having a discussion here. You are claiming that the collection-based iteration is inherently slower than a classical numeri

[swift-evolution] [Suggestion] Case-based dispatch for enum methods

Recently, I have been working on implementing some non-trivial data structures in Swift (its about storing polygons in a space-partitioning tree). I am using enums to represent different types of parent nodes and leafs and I had some ideas to make them more fit for this kind of work. I expect th

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

> On 30 Mar 2016, at 22:05, Ted F.A. van Gaalen via swift-evolution > wrote: > > Again I need to emphasize very strongly that this for-loop really > has absolutely > nothing, nada, zilch, niente, nichts, niets, niks, rien, zero, nenio, > to do with the: > > for i in stride(…. > > or

Re: [swift-evolution] Thoughts regarding readable INTENT of Loop keywords

I do not see how this is more readable. The current for loop is perfectly readable and conveys the intent very well IMO: it executes a code block FOR every ELEMENT that is IN a SEQUENCE. In contrast, I find your proposal rather confusing: it combines a number of different constructions with diff

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

> On 21 Mar 2016, at 17:05, ted van gaalen wrote: > > Hello Taras > Please take a look here: > https://en.m.wikipedia.org/wiki/For_loop > > > More than 30 ! programming languages since 1957 until now, have their > implementation of the for-loop. If

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

To be honest, I have difficulty understanding the premise of this discussion. I have always found the C-style for(;;) loop an awkward construct, because it is essentially just an alternative form of writing a general-purpose while loop. It is perfectly reasonable to restrict the for construct

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

gt;> struct etc. I can also imagine combining it with assignment, e.g. instead >>>>> of >>>>> >>>>> let obj = MyClass() >>>>> do with obj { >>>>> prop1 = v1 >>>>> setup2() >>>>> } &g

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

> struct etc. I can also imagine combining it with assignment, e.g. instead >>>>> of >>>>> >>>>> let obj = MyClass() >>>>> do with obj { >>>>> prop1 = v1 >>>>> setup2() >>>>> } &g

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

form such as >>>> >>>> do with let obj = MyClass() { >>>> prop1 = v1 >>>> setup2() >>>> } >>> I think in this case it’s important to define scope of obj - it should be >>> only “do with”, not the the outer one? &

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

o instance methods? Anything you can access with the dot notation. > > -Mosab Elagha > > On Sun, Dec 27, 2015 at 3:13 PM, Radosław Smogura <mailto:swift-evolution@swift.org>> wrote: > Hi, > > That’s a great idea! > > Kind regards, > Radek > > > On

[swift-evolution] [Proposal] Lexical scope statement (with .. do)

Quite often, one needs to perform a number of operations on a single object (e.g. call up a bunch of configuration or action methods). This proposal is to extend the ‘do' statement with an explicit lexical scope feature. For instance, this piece of code object.do_something() object.do_someth