diff --git a/docs/manual/faq.md b/docs/manual/faq.md index 00b6456..fbf715f 100644 --- a/docs/manual/faq.md +++ b/docs/manual/faq.md @@ -1,51 +1,172 @@ -# Frequently Asked Questions +# Frequently Asked Questions(سوالات پرتکرار) ## General -### Is Julia named after someone or something? - -No. - -### Why don't you compile Matlab/Python/R/… code to Julia? - -Since many people are familiar with the syntax of other dynamic languages, and lots of code has already been written in those languages, it is natural to wonder why we didn't just plug a Matlab or Python front-end into a Julia back-end (or “transpile” code to Julia) in order to get all the performance benefits of Julia without requiring programmers to learn a new language. Simple, right? - -The basic issue is that there is *nothing special about Julia's compiler*: we use a commonplace compiler (LLVM) with no “secret sauce” that other language developers don't know about. Indeed, Julia's compiler is in many ways much simpler than those of other dynamic languages (e.g. PyPy or LuaJIT). Julia's performance advantage derives almost entirely from its front-end: its language semantics allow a [well-written Julia program](@ref man-performance-tips) to *give more opportunities to the compiler* to generate efficient code and memory layouts. If you tried to compile Matlab or Python code to Julia, our compiler would be limited by the semantics of Matlab or Python to producing code no better than that of existing compilers for those languages (and probably worse). The key role of semantics is also why several existing Python compilers (like Numba and Pythran) only attempt to optimize a small subset of the language (e.g. operations on Numpy arrays and scalars), and for this subset they are already doing at least as well as we could for the same semantics. The people working on those projects are incredibly smart and have accomplished amazing things, but retrofitting a compiler onto a language that was designed to be interpreted is a very difficult problem. - -Julia's advantage is that good performance is not limited to a small subset of “built-in” types and operations, and one can write high-level type-generic code that works on arbitrary user-defined types while remaining fast and memory-efficient. Types in languages like Python simply don't provide enough information to the compiler for similar capabilities, so as soon as you used those languages as a Julia front-end you would be stuck. - -For similar reasons, automated translation to Julia would also typically generate unreadable, slow, non-idiomatic code that would not be a good starting point for a native Julia port from another language. - -On the other hand, language *interoperability* is extremely useful: we want to exploit existing high-quality code in other languages from Julia (and vice versa)! The best way to enable this is not a transpiler, but rather via easy inter-language calling facilities. We have worked hard on this, from the built-in `ccall` intrinsic (to call C and Fortran libraries) to [JuliaInterop](https://github.com/JuliaInterop) packages that connect Julia to Python, Matlab, C++, and more. +### Is Julia named after someone or something?(ایا اسم جولیا برگرفته از شخص یا چیزی است؟) + +خیر + +### Why don't you compile Matlab/Python/R/… code to Julia?(چرا کد متلب و ار و پایتون روی جولیا اجرا نمی شود؟) +
+ از انجایی که بسیاری از مردم با سینتکس بقیه زبان های داینامیک برناهم نویسی اشنا هستند و بسیاری از کد ها به این زبانها نوشته شده است،طبیعی است که تعجب کنید چرا سیتکس زبان هایی مثل + mathlab + یا + python + را نگرفتیم و با + backend + جولیا به اصطلاح + transpile + کنیم تا تمام مزایای عملکردی جولیا را داشته باشیم بدون اینکه نیاز باشد برنامه نویس یک زبان جدید یاد بگیرد . + ساده است ؟ بله؟ +
+ مسئله اولیه این است که هیچ چیز خاصی درباره کامپایلر جولیا وجو ندارد ما از یک کامپایلر + LLVM + بدون هیچ چیز اضافه ای که برنامه نویس های دیگر درباره ان نمیدانند استفاده نکردیم . + قطعا کامپایلر جولیا ار خیلی جهات به مراتب ساده تر از زبانهایی مثل + PyPy or LuaJIT + است. + مزایای + عملکرد جولیا + برگرفته از قسمت + front-end + ان است. + معنا شناسی + (semantics) + ان این اجازه را میدهد که یک برنامه نویس خوب این اجازه را به کامپایلز بدهد که کدهای بهتری از لحظ موثر بودن و لایه های مموری تولید کند. + اگر شما تا به حال کامپایل کردن کد های + mathlab + یا + python + را در جولیا امتحان کرده باشید،کامپایلر زبان محدود میشود و نمیتواند کد های بهتری نسبت به کامپابلر همان زبان پایتون یا جنریت و تولید کند. + (و شاید هم بدتر) + نکته کلیدی عملکرد فهمیدن کد این است که چرا کامپابلر های پایتون مثل + Numba + یا + Pythran + تنها تلاش میکنند که زیرمجموعه کوچکی از زبان را اپتیمایز کنند مثل + عمل هایی بر روی ارایه و اعداد در + numpy + و برای همین زیرمجموعه هم خیلی کمتر از برنامه نویسان جولیا کار را انجام میدهند . + افرادی که روی این پروژه ها کار میکنند بسیار باهوش هستند و + کارهای شگفت انگیزی انجام داده اند . + اما مقاوم سازی مجدد یک کامپایلر بر روی زبانی که برای تفسیر + (interpreting) + طراحی شده است ، یک مشکل بسیار دشوار است. +
+ مزیت جولیا نسبت این است که این عملکرد خوب و اپتیمایز بر روی یک زیرمجموعه تایپ ها و عملگر های + “built-in” + محدود نشده است و برنامه نویس میتواند یک یک برنامه بسطح بالا با تایپ عمومی بنویسد که بر روی + انواع مختلف + type-generic code + توسط کاربر تعریف شده درحلیکه هنوز سریع و از نظر حتفظه کم حافظه است. + تایپ ها در زبانهایی مثل پایتون به سادگی اطلاعات زیادی با این توان در اختیار کامپایلر قرار نمیدهند + . + و تا زمانی که از انها برای + front-end + جولیا استفاده میکنید از این ویژگی نیمتوانید بهر ببرید. +
+ به دلایل مشابه +automated translation + نیز برای جولیا یک کد ناخوانا و ارام به نسبت و نه اصطلاحی + (منظور این است که مختص به جولیا باشد.) + تولید می کند که نقطه شروعی برای یک زبان + (native) +مثل جولیا + نیست. +
+ در طورف دیگر ویژگی +*interoperability* + یک زبان بسیار بدردبخور است . + ما می خواهیم از کد با کیفیت بالا موجود به زبانهای دیگر از جولیا (و بالعکس) بهره برداری کنیم! +بهترین راه برای اینکار یک + transpiler + نیست بلکه از طریق ویژگی هایی است که در خود زبان تعبیه شده + (easy inter-language calling facilities) + ما به سختی روی این موضوع کار کردیم از + ccall + داخلی برای ارتباط با زبان + C + و کتابخانه های +Fortran + به +پکیج های + juliaInterop +که زبان جولیا را به پایتون و متلب و سی پلاس پلاس و غیره مرتبط میکنند. + +
## Sessions and the REPL -### How do I delete an object in memory? +### How do I delete an object in memory?(چگونه یک شی را از مموری پاک کنیم ؟) +
+ جولیا مانند + mathlab + یک تابع + clear + ندارد . + وقتی که یک اسم در یک + session + جولیا تعریف شد. + ( + دقیق تر در ماژول + main + ) + همیشه انجا وجود دارد. +
+اگر استفاده از مموری جز نگرانی های شماست ،میتوانید همیشه اشیای خود را با ان هایی که فضا یا مموری کمتری می گیرند جا به جا کنید. +
+ برای مثال اگر + A + یک ارایه با سایز اردر گیگابایت باشد و دیگر در برنامه نیازی به ان نباشد،میتوانید با دستور + A = nothing + مموری را خالی کنید. + و ان فضا دفعه بعدی که + garbage collector + اجرا شد فضا را خالی میکند. + و همینطور میتوانید با تابع زیر ان را مجبور به اجرا کنید . +
+ GC.gc() + که در + Base + قرار دارد + همین طور استفاده از + َA + به احتمال زیاد در این حالت منجر به خطا میشود. + زیرا بیشتر توابع بر روی تایپ + nothing + تعریف نشده اند . + +
+ +### How can I modify the declaration of a type in my session?(چگونه تایپ را عوض میکنم؟) +
+ شاید شما نوعی را تعریف کرده باشید و سپس متوجه شوید که باید یک قسمت جدید اضافه کنید. + اگر اینکار را بر روی + REPL + امتحان کرده باشید ، خطای زیر را دریافت می کنید + : +
-Julia does not have an analog of MATLAB's `clear` function; once a name is defined in a Julia -session (technically, in module `Main`), it is always present. - -If memory usage is your concern, you can always replace objects with ones that consume less memory. - For example, if `A` is a gigabyte-sized array that you no longer need, you can free the memory -with `A = nothing`. The memory will be released the next time the garbage collector runs; you can force -this to happen with [`GC.gc()`](@ref Base.GC.gc). Moreover, an attempt to use `A` will likely result in an error, because most methods are not defined on type `Nothing`. - -### How can I modify the declaration of a type in my session? - -Perhaps you've defined a type and then realize you need to add a new field. If you try this at -the REPL, you get the error: ``` ERROR: invalid redefinition of constant MyType ``` - -Types in module `Main` cannot be redefined. - -While this can be inconvenient when you are developing new code, there's an excellent workaround. - Modules can be replaced by redefining them, and so if you wrap all your new code inside a module -you can redefine types and constants. You can't import the type names into `Main` and then expect -to be able to redefine them there, but you can use the module name to resolve the scope. In other -words, while developing you might use a workflow something like this: +
+ تایپ ها در ماژول + main + نمیتوانند دوباره تعریف شوند. +
+ اگرچه این کار در هنگام نوشتن کد جدید ناخوشایند است ، اما یک راه حل عالی وجود دارد. +ماژول ها میتوانند با دوباره تعریف کردنشان جا به جا شوند. + پس اگر شما کد خود را دورن یک ماژول بپیچید + به اصطلاح + wrap + کنید میتوانید ثابت ها و تایپ ها را دوباره تعریف کنید. +، + نمی توانید نام نوع را در "Main" وارد کنید و سپس انتظار داشته باشید +برای اینکه بتوانید در آنجا دوباره تعریف کنید ، اما می توانید از نام ماژول برای حل محدوده استفاده کنید. در دیگر +سخن ، در حالی که شما ممکن است از گردش کار مانند این استفاده کنید: +
```julia include("mynewcode.jl") # this defines a module MyModule @@ -61,31 +182,72 @@ obj3 = MyModule.someotherfunction(obj2, c) ## [Scripting] -### How do I check if the current file is being run as the main script? - -When a file is run as the main script using `julia file.jl` one might want to activate extra -functionality like command line argument handling. A way to determine that a file is run in -this fashion is to check if `abspath(PROGRAM_FILE) == @__FILE__` is `true`. +### How do I check if the current file is being run as the main script?(چگونه چک کنم این فایل دارد روی جریان اصلی اجرا میشود یا نه؟) +
+ زمانی که یک فایل با استفاده از + julia file.jl + بر روی + main script + اجرا میشود، +یک نفر ممکن است بخواهد عملکردهای دیگری اضافه بر سازمان مانند کنترل ارگومتن در + command line + را فعال کند . + روشی برای تعیین اینکه یک فایل به این صورت اجرا شده است ، این است که ایا +
+ +`abspath(PROGRAM_FILE) == @__FILE__` is `true`. ### [How do I catch CTRL-C in a script?] - -Running a Julia script using `julia file.jl` does not throw -[`InterruptException`](@ref) when you try to terminate it with CTRL-C -(SIGINT). To run a certain code before terminating a Julia script, -which may or may not be caused by CTRL-C, use [`atexit`](@ref). -Alternatively, you can use `julia -e 'include(popfirst!(ARGS))' -file.jl` to execute a script while being able to catch -`InterruptException` in the [`try`](@ref) block. +
+ اجرا کردن یک اسکریپت جولیا با استفاده از + julia file.jl + اکسپشن + InterruptExeption + را پرت نمیکند. +زمانی که شما این پروسه را با زدن + CTRL-C +(SIGINT) + تمام میکنید. + برای اجرا کردن کد قبل از بستن یک اسکریپت جولیا که ممکن است با + CTRL-C + ویا بدون ان ایجاد شده باشد، +از +atexit + استفاده کنید همین طور ، میتوانید از +julia -e 'include(popfirst!(ARGS)) +file.jl +برای اجرا کردن یک اسکریپت زمانی که میتوانید اکسپشن + InterruptExeption + را در بلاک + try + catch + کنید. +
### How do I pass options to `julia` using `#!/usr/bin/env`? - -Passing options to `julia` in so-called shebang by, e.g., -`#!/usr/bin/env julia --startup-file=no` may not work in some -platforms such as Linux. This is because argument parsing in shebang -is platform-dependent and not well-specified. In a Unix-like -environment, a reliable way to pass options to `julia` in an -executable script would be to start the script as a `bash` script and -use `exec` to replace the process to `julia`: +
+ پاس دادن اپشن ها به + `julia` +در اصطلاح + shebang + گفته میشود. +#!/usr/bin/env julia --startup-file=no + ممکن است در بعضی از پلتفرم ها مثل لینوکس کار نکند. + که این به این خاطر است که ارگومانی که در +shebang + کار + parsing + بر روی ان انجام شده است نسبت به پلتفرم مستقل نیست و به ان بستگی دارد. + یک راه قابل اطمینان برای پاس دادن اپشن ها به +`julia` + در یک اسکریپت قابل اجرا میتواند این باشد که اسکریپت را مانند + bash + اسکریت شروع کنند و از + exec + برای انتقال پروسه به + julia + استفاده کنند. +
```julia #!/bin/bash @@ -96,13 +258,40 @@ exec julia --color=yes --startup-file=no "${BASH_SOURCE[0]}" "$@" @show ARGS # put any Julia code here ``` -In the example above, the code between `#=` and `=#` is run as a `bash` -script. Julia ignores this part since it is a multi-line comment for -Julia. The Julia code after `=#` is ignored by `bash` since it stops -parsing the file once it reaches to the `exec` statement. - -!!! note - In order to [catch CTRL-C](@ref catch-ctrl-c) in the script you can use +
+ در مثال بالا ، کدی که بین + #= + و + =# + بود به صورت + `bash` +script + اجرا شد. + جولیا به این بخش کاری ندارد تا وقتیی که یک کامنت چند خطه برای جولیاست. + کد های جولیا بعد از علامت + =# + توسط + bash + ایگنور میشوند (ران نمیشوند) + تا زمانی که در + parse + کردن فایل متوقف شود زمانی که + state + ما یعنی + exec + میرسد. +
+ توجه کنید برای +
+ + + [catch CTRL-C](@ref catch-ctrl-c) + + +
+ بر روی اسکریپت میتوانید +
+ ```julia #!/bin/bash #= @@ -114,11 +303,14 @@ parsing the file once it reaches to the `exec` statement. ``` instead. Note that with this strategy [`PROGRAM_FILE`](@ref) will not be set. -## Functions +## Functions(توابع) -### I passed an argument `x` to a function, modified it inside that function, but on the outside, the variable `x` is still unchanged. Why? +### I passed an argument `x` to a function, modified it inside that function, but on the outside, the variable `x` is still unchanged. Why?(چرا من یک متغیر را درون تابع تغییر دادم ولی بیرون ان تغییر نکرده است؟) -Suppose you call a function like this: +
+ فرض کنید چنین تابعی را صدا کرده اید + : +
```jldoctest julia> x = 10 @@ -136,14 +328,42 @@ julia> x # x is unchanged! 10 ``` -In Julia, the binding of a variable `x` cannot be changed by passing `x` as an argument to a function. -When calling `change_value!(x)` in the above example, `y` is a newly created variable, bound initially -to the value of `x`, i.e. `10`; then `y` is rebound to the constant `17`, while the variable -`x` of the outer scope is left untouched. - -However, if `x` is bound to an object of type `Array` -(or any other *mutable* type). From within the function, you cannot "unbind" `x` from this Array, -but you *can* change its content. For example: +
+ در جولیا، +مقداری که به یک متغیر نسبت داده شده یا + binding of a variable + x + نمیتواند در اثر پاس دادن به یک ارگومان تابع تغییر کند . + وقتی تابع + hange_value!(x) + در مثال بالا را صدا می زنیم،متغیر + y + یک متغیر است که به سادگی ساخته شده است . + که اول در تابع یک مقدار به مقدار + x + می دهد مقدار 10 + سپس + y + مقدار 17 میگیرد. + هنگامی که متغیر + x + در لایه خارجی هنوز دست نخورده است. +
+ درحالیکه،اگر + x + به یک شی از ارایه + assign + میشد + (یا هر تایپ + mutable( + از داخل تابع ،نمیتوانید اشاره گر + x + را عوض کنید یا به اصطلاح + unbind + اش کنید ولی میتوانید مقدارش را عوض کنید. + برای مثال + : +
```jldoctest julia> x = [1,2,3] @@ -167,18 +387,38 @@ julia> x 3 ``` -Here we created a function `change_array!`, that assigns `5` to the first element of the passed -array (bound to `x` at the call site, and bound to `A` within the function). Notice that, after -the function call, `x` is still bound to the same array, but the content of that array changed: -the variables `A` and `x` were distinct bindings referring to the same mutable `Array` object. - -### Can I use `using` or `import` inside a function? - -No, you are not allowed to have a `using` or `import` statement inside a function. If you want -to import a module but only use its symbols inside a specific function or set of functions, you -have two options: - -1. Use `import`: +
+ اینجا ما یک تابع + change_array! + ساختیم که به خانه اول ارایه مقدار + '5' + را نسبت میدهد. + دقت کنید بعد از فراخوانی تابع، + x + هنوز به همان ارایه اشاره میکند. + ولی مقادیر ارایه فرق کرده است . + متغیر های + A + و + x + دو اشاره گر متمایز بودند که به یک ارایه تغییر پیدا کرده اشاره میکردند. +
+ +### Can I use `using` or `import` inside a function?(ایا میتوانیم از این دو لفظ درون تابع استفاده کنیم؟) + +
+ نه ! ما اجازه نداریم که از کلیدواژه های + using + یا + import + درون تابع استفاده کنیم. + اگر میخواهید که یک ماژول را ایمپورت کنید ولی فقط از سمبل های درون یک تابع مشخص یا مجموعه ای از تابع ها استفاده کنید. + دو تا راه دارید + : +
+
+ 1.از ایمپورت استفاده کنید: +
```julia import Foo @@ -186,11 +426,23 @@ have two options: # ... refer to Foo symbols via Foo.baz ... end ``` - - This loads the module `Foo` and defines a variable `Foo` that refers to the module, but does not - import any of the other symbols from the module into the current namespace. You refer to the - `Foo` symbols by their qualified names `Foo.bar` etc. -2. Wrap your function in a module: +
+ این کد ماژول + Foo + را لود میکند و یک متغیر + Foo + را تعریف میکند . + که به ماژول برمیگردد ولی هنوز هیچکدام از سیمبل های دیگر از ماژول را به + namespace + فعلی ایمپورت نمیکند. + شما با اسم های واجدشرایط + qualified names `Foo.bar` + به + Foo + اشاره می کنید. +
+ 2.تابع خود را در یک ماژول قرار دهید: +
```julia module Bar @@ -203,20 +455,35 @@ have two options: using Bar ``` - This imports all the symbols from `Foo`, but only inside the module `Bar`. +
+ این کد تمام + symbol + ها را از + Foo + ایمپورت میکند ولی فقط درون ماژول + Bar. +
### What does the `...` operator do? #### The two uses of the `...` operator: slurping and splatting - -Many newcomers to Julia find the use of `...` operator confusing. Part of what makes the `...` -operator confusing is that it means two different things depending on context. +
+ بسیاری از افرادی که به تازگی با جولیا کد میزنند،در استفاده از عملگر + ... + گیج میشوند. + یکی از دلایلی که این عملگر پیچیده است این است که با توجه به کانتکس مفهوم متفاوتی دارد. +
#### `...` combines many arguments into one argument in function definitions - -In the context of function definitions, the `...` operator is used to combine many different arguments -into a single argument. This use of `...` for combining many different arguments into a single -argument is called slurping: +
+ برخلاف استفاده عملگر + ... + که اجازه میدهد هرچقدر ارکومان که خواستیم ورودی بدهیم،همان عملگر همچنین برای ایجاد یک تابع که فقط یک ارگومان داردکه باید از سایر ارگومان ها جدا باشدوقتی در کانتکستفراخوانی تابع از ان صحبت می شود. + این استفاده از این عملگر + slurping + نام دارد + : +
```jldoctest julia> function printargs(args...) @@ -233,16 +500,31 @@ Arg #1 = 1 Arg #2 = 2 Arg #3 = 3 ``` - -If Julia were a language that made more liberal use of ASCII characters, the slurping operator -might have been written as `<-...` instead of `...`. - -#### `...` splits one argument into many different arguments in function calls - -In contrast to the use of the `...` operator to denote slurping many different arguments into -one argument when defining a function, the `...` operator is also used to cause a single function -argument to be split apart into many different arguments when used in the context of a function -call. This use of `...` is called splatting: +
+ اگر جولیا یک زبان بود که با استفاده از کاراکتر های + ASCII + حرف های بیشتری میساخت، +عملگر + slurping + باید به جای + ... + به صورت +<-... + نوشته میشد. +
+ +#### `...` splits one argument into many different arguments in function calls(جدا کردن یک ارگومان از دیگر ارگومان ها در هنگام صدا کردن ان ) + +
+ برخلاف استفاده عملگر + ... + که اجازه میدهد هرچقدر ارکومان که خواستیم ورودی بدهیم،همان عملگر همچنین برای ایجاد یک تابع که فقط یک ارگومان داردکه باید از سایر ارگومان ها جدا باشدوقتی در کانتکستفراخوانی تابع از ان صحبت می شود. + این استفاده از این عملگر + splatting + نام دارد + : + +
```jldoctest julia> function threeargs(a, b, c) @@ -263,13 +545,26 @@ a = 1::Int64 b = 2::Int64 c = 3::Int64 ``` - -If Julia were a language that made more liberal use of ASCII characters, the splatting operator -might have been written as `...->` instead of `...`. +
+ اگر جولیا یک زبان بود که با استفاده از کاراکتر های + ASCII + حرف های بیشتری میساخت، +عملگر + splatting + باید به جای + ... + به صورت + ...-> + نوشته میشد. +
### What is the return value of an assignment? - -The operator `=` always returns the right-hand side, therefore: +
+ عملگر + = + همیشه نتیجه محاسبه سمت راست خود را برمیگرداند + : +
```jldoctest julia> function threeint() @@ -289,8 +584,11 @@ julia> threeint() julia> threefloat() 3.0 ``` +
+ و به طور مشابه + : +
-and similarly: ```jldoctest julia> function threetup() diff --git a/docs/manual/style-guide.md b/docs/manual/style-guide.md index c83d1f7..f7adff7 100644 --- a/docs/manual/style-guide.md +++ b/docs/manual/style-guide.md @@ -1,50 +1,107 @@ -# Style Guide - -The following sections explain a few aspects of idiomatic Julia coding style. None of these rules -are absolute; they are only suggestions to help familiarize you with the language and to help -you choose among alternative designs. +# Style Guide(راهنمای سبک نوشتن) +
+ در این بخش ها ما به بررسی بخش از عبارات اصطلاحی در نوشتن برنامه به زبان جولیا می پردازیم + . + هیچ کدام از این قوانین مطلق نیستند + . + انها تنها برای کمک به اشنا شدن شما با زبان و کمک برای انتخاب بین راه حل های طراحی موجود است + . +
## Indentation - -Use 4 spaces per indentation level. - -## Write functions, not just scripts - -Writing code as a series of steps at the top level is a quick way to get started solving a problem, -but you should try to divide a program into functions as soon as possible. Functions are more -reusable and testable, and clarify what steps are being done and what their inputs and outputs -are. Furthermore, code inside functions tends to run much faster than top level code, due to how -Julia's compiler works. - -It is also worth emphasizing that functions should take arguments, instead of operating directly -on global variables (aside from constants like [`pi`](@ref)). - -## Avoid writing overly-specific types - -Code should be as generic as possible. Instead of writing: +
+ برای سطح های مختلف + indentation + از 4 تا اسپیس می توانید استفاده کنید + . +
+ +## Write functions, not just scripts(نوشتن توابع) +
+ یکی از راه های سریع حل یک مسئله، نوشتن کد به صورت یک سری گام در بالاترین سطح است ولی بهتر است هر چه سریعتر برنامه خود را به یکسری تابع تقسیم کنید + . + توابع بهتر از حالت قبل قابل استفاده مجدد و تست شدن هستند + , + واینکه چه گام هایی تمام شده اند و چه ورودی ها و خروجی هایی داشتند را مشخص میکنند + . + در ادامه در زبان جولیا کد های داخل توابع + ، + سریعتر از کد های سطح اول اجرا می شوند + . + که این به عملکرد کامپایلر جولیا بازمی گردد + . +
+
+ همین طور تاکیید این نکته مهم است که توابع بهتر است + ورودی بگیرند به جای اینکه به صورت + global + از متغیر ها استفاده کنند + . + ) + جدای از ثابت ها مانند + +
+ + [`pi`](@ref)) + +## Avoid writing overly-specific types(جلوگیری از نوشتن تایپ های بیش از حد مشخص) + +
+کد باید تا جایی که میتوانیم + generic + عمومی باشد + . + به جای رویه زیر +
```julia Complex{Float64}(x) ``` - -it's better to use available generic functions: +
+ بهتر است که از توابع در دسترس عمومی + ) + اصطلاحا + genenric + استفاده شود + . +
```julia complex(float(x)) ``` +
+ رویه دوم + `x` + را به تایپ مورد نظر تبدیل میکند + . + به جای اینکه همیشه به یک نوع تبدیل کند + . +
+
+ این طرز نوشتن مخصوصا مربوط به ورودی های تابع است + . + برای مثال ما نوع ارگومان را + `Int` + یا + Int32 + + در واقع ،در بیشتر اوقات تایپ یا نوع ورودی را میتوانید اعلام نکنید مگر اینکه برای ابهام زدایی از سایر توابع لازم باشداگر نوعی که به ارگومان داده میشودتوسط هیچ یک از +اسم گذاری های تابع معتبر نباشد،یک ارور + MethodError + به ما داده میشود + . + به این مسئله + duck typing + می گویند + . +
+
+ برای مثال تعریف زیر را برای تابع + addone + در نظر بگیرید که عدد یک را با ارگومان ورودیش جمع می کند + : +
-The second version will convert `x` to an appropriate type, instead of always the same type. - -This style point is especially relevant to function arguments. For example, don't declare an argument -to be of type `Int` or [`Int32`](@ref) if it really could be any integer, expressed with the abstract -type [`Integer`](@ref). In fact, in many cases you can omit the argument type altogether, -unless it is needed to disambiguate from other method definitions, since a -[`MethodError`](@ref) will be thrown anyway if a type is passed that does not support any -of the requisite operations. (This is known as -[duck typing](https://en.wikipedia.org/wiki/Duck_typing).) - -For example, consider the following definitions of a function `addone` that returns one plus its -argument: ```julia addone(x::Int) = x + 1 # works only for Int @@ -52,19 +109,50 @@ addone(x::Integer) = x + oneunit(x) # any integer type addone(x::Number) = x + oneunit(x) # any numeric type addone(x) = x + oneunit(x) # any type supporting + and oneunit ``` +
+ اخرین تعریف + addone + برای تمام ارگومان ها از نوع + oneunit + ) + که یکی را برمی گرداند که هم نوع + 'x' + باشد که از تایپی که مناسب نباشد و در نتیجه به ارور برخورد کردن خودداری میکند + وتابع + '+' + با ان ارگومان اجرا میشود + . + نکته مهم این است که ما هیچ مشکلی در اجرا و عملکرد + `addone(x) = x + oneunit(x)` + نسبت به حالتی که تایپ را بنویسیم نداریم + ) + به طور اصطلاح +we dont have performance penalty + ( + چون جولیا به طور اتوماتیک تابع + `addone` + را به ازای ارگومان + `x::Int` + صدا میزند + و + `oneunit` + با + 1 + جایگزین می شود + . + بنابراین هر سه تعریف اول از تابع + `addone` + به طور کامل به تعریف چهارم کاهش می یابند + . +
+ +## Handle excess argument diversity in the caller(تعدد ارگومان در تابع) + +
+ به جای + : +
-The last definition of `addone` handles any type supporting [`oneunit`](@ref) (which returns 1 in -the same type as `x`, which avoids unwanted type promotion) and the [`+`](@ref) function with -those arguments. The key thing to realize is that there is *no performance penalty* to defining -*only* the general `addone(x) = x + oneunit(x)`, because Julia will automatically compile specialized -versions as needed. For example, the first time you call `addone(12)`, Julia will automatically -compile a specialized `addone` function for `x::Int` arguments, with the call to `oneunit` -replaced by its inlined value `1`. Therefore, the first three definitions of `addone` above are -completely redundant with the fourth definition. - -## Handle excess argument diversity in the caller - -Instead of: ```julia function foo(x, y) @@ -73,8 +161,10 @@ function foo(x, y) end foo(x, y) ``` - -use: +
+ از این کد استفاده کنید + : +
```julia function foo(x::Int, y::Int) @@ -82,17 +172,32 @@ function foo(x::Int, y::Int) end foo(Int(x), Int(y)) ``` - -This is better style because `foo` does not really accept numbers of all types; it really needs -`Int` s. - -One issue here is that if a function inherently requires integers, it might be better to force -the caller to decide how non-integers should be converted (e.g. floor or ceiling). Another issue -is that declaring more specific types leaves more "space" for future method definitions. +
+ این سبک نوشتن بهتر است زیرا دیگر ارگومان هایی از نوع دیگر را قبول نمیکند و باعث اشتباه کمتر برنامه نویس می شود + . + وفقط نوع + `Int` + را قبول میکند + . +
+
+ یک مسئله اینجا این است که این تابع به صورت ذاتی فقط + integer + قبول میکند + . + شاید بهتر بود تابع تضمیم بگیرد که با + non-integers + چگونه تصمیم بگیرد + (مانند کف یا سقف گرفتن عمل کند) + مسئله دیگر این است که این دقیق مشخص کردن نوع ورودی ارگومان توابع ابتکار عمل را برای تعاریف بدی تابع می گیرد + . +
## [Append `!` to names of functions that modify their arguments] - -Instead of: +
+ به جای + : +
```julia function double(a::AbstractArray{<:Number}) @@ -102,8 +207,10 @@ function double(a::AbstractArray{<:Number}) return a end ``` - -use: +
+ از این کد استفاده کنید + : +
```julia function double!(a::AbstractArray{<:Number}) @@ -113,176 +220,419 @@ function double!(a::AbstractArray{<:Number}) return a end ``` - -Julia Base uses this convention throughout and contains examples of functions -with both copying and modifying forms (e.g., [`sort`](@ref) and [`sort!`](@ref)), and others -which are just modifying (e.g., [`push!`](@ref), [`pop!`](@ref), [`splice!`](@ref)). It -is typical for such functions to also return the modified array for convenience. - -## Avoid strange type `Union`s - -Types such as `Union{Function,AbstractString}` are often a sign that some design could be cleaner. - -## Avoid elaborate container types - -It is usually not much help to construct arrays like the following: +
+همچنین + Julia Base + از این روش مرسوم استفاده میکند و توابعی با هر دو صورت کپی شده و اصلاح شده استفاده میکند + . +
+ + (e.g., [`sort`](@ref) and [`sort!`](@ref)) +
+و بقیه فقط فزم اصلاح شده اند + . + و این برای چنین توابعی عادی است که ارایه اصلاح شده را برگردانند + . +
+ + (e.g., [`push!`](@ref), [`pop!`](@ref), [`splice!`](@ref)) + + +## Avoid strange type `Union`s(از نوع های عجیب "اجتماع " دوری کنید) +
+ تایپ ها یا نوع هایی مثل + `Union{Function,AbstractString}` + نشانه هایی هستند که طراحی شما میتوانست بهتر و تمیز تر باشد + . +
+ +## Avoid elaborate container types(از نوع های در برگیرنده پیچیده بپرهیزید) +
+ معمولا ساخت ارایه به صورت زیر کمک شایانی نمی کند + : +
```julia a = Vector{Union{Int,AbstractString,Tuple,Array}}(undef, n) ``` - -In this case `Vector{Any}(undef, n)` is better. It is also more helpful to the compiler to annotate specific -uses (e.g. `a[i]::Int`) than to try to pack many alternatives into one type. - +
+ در این حالت + `Vector{Any}(undef, n)` + بهتر است . + و همچنین برای کامپایلر کمک کننده تراست که یک حاشیه نویسی هایی به صورت زیر انجام دهد که + بسیاری از نوع های جایگزین را به یک نوع تبدیل کند + . +
+ + (e.g. `a[i]::Int`) + ## Use naming conventions consistent with Julia `base/` - - * modules and type names use capitalization and camel case: `module SparseArrays`, `struct UnitRange`. - * functions are lowercase ([`maximum`](@ref), [`convert`](@ref)) and, when readable, with multiple - words squashed together ([`isequal`](@ref), [`haskey`](@ref)). When necessary, use underscores - as word separators. Underscores are also used to indicate a combination of concepts ([`remotecall_fetch`](@ref) - as a more efficient implementation of `fetch(remotecall(...))`) or as modifiers. - * conciseness is valued, but avoid abbreviation ([`indexin`](@ref) rather than `indxin`) as - it becomes difficult to remember whether and how particular words are abbreviated. - -If a function name requires multiple words, consider whether it might represent more than one -concept and might be better split into pieces. +
+ * + ماژول ها و نوع متغیر ها از حروف بزرگ تشکیل شده اند و در اصطلاح + camel case + هستند برای مثال + `module SparseArrays` + و + `struct UnitRange` +
+ * + توابع با حروف کوچک یا به اصطلاح + lowercase + هستند + . + مانند + `maximum` + و + `convert` + و وقتی از چند کلمه تشکیل شده باشد + مانند + `isequal` + و + `haskey` + . + اگر لازم بود + از + underscore + به عنوان کلمه جدا کن استفاده منید + . + underscores + معمولا برای نشان دادن ترکیب چند موضوع استفاده می شوند + مثلا + `remotecall_fetch` + ورژن با عملکرد بهتر برای تابع + `fetch(remotecall(...))` + است + . +
+ * + مختصر نوشتن خیلی خوب است ولی از خلاصه نویسی بپرهیزید برای مثال + `indexin` + بهتر است از + `indxin` + چون باعث میشود سخت تر به یاد بیاوریم که هر لغت مختصر شده کدام کلمه است + . + +
+ +
+ اگربرای اسم یک تابع به چند کلمه نیاز داشتید ،این موضوع را که به چند تا موضوع مربوط است و بهتر است انها را به چند تا تابع تقسیم کنید + . +
## Write functions with argument ordering similar to Julia Base - -As a general rule, the Base library uses the following order of arguments to functions, -as applicable: - -1. **Function argument**. - Putting a function argument first permits the use of [`do`](@ref) blocks for passing - multiline anonymous functions. +
+ به عنوان قانونی کلی کتابخانه + BASE + از ترتیب زیر برای ارگومان های تابع استفاده میکند. + : +
+1. **ارگومان تابع**. +
+اضافه کردن ارگومان تابع به ما اجازه میدهد که از بلاک + do + استفاده کنیم . + برای اجرا کردن توابع چندخطی + anonymous + . +
2. **I/O stream**. - Specifying the `IO` object first permits passing the function to functions such as - [`sprint`](@ref), e.g. `sprint(show, x)`. - +
+مشخص کردن اینکه اشیا + `IO` + اجازه میدهند تابع به توابع دیگر مثل + `sprint(show, x)` + پاس داده شود + . +
+ + [`sprint`](@ref) + 3. **Input being mutated**. - For example, in [`fill!(x, v)`](@ref fill!), `x` is the object being mutated and it - appears before the value to be inserted into `x`. +
+برای مثال در تابع + `fill!(x, v)` + متغیر + `x` + شئ است که جهش یافته + (mutated) + و قبل از مقدار قرار داده شده در + `x` + ظاهر میشود + . +
4. **Type**. - Passing a type typically means that the output will have the given type. - In [`parse(Int, "1")`](@ref parse), the type comes before the string to parse. - There are many such examples where the type appears first, but it's useful to note that - in [`read(io, String)`](@ref read), the `IO` argument appears before the type, which is - in keeping with the order outlined here. +
+پاس دادن یک تایپ (یا نوع)به طور عادی به این معنی است که خروجی ما به طور عادی به صورت همان نوع داده شده است . + در تابع + `parse(Int, "1")` + تایپ مورد نظر قبل از رشته ای که باید + parse + شود می اید + . + در بسیاری از مثال ها که نوع خروجی اول می اید ولی مفید است که ذکر کنیم که + ارگومان + `IO` + در تابع + `read(io, String)` + قبل از تایپ (نوع) ظاهر می شود که مطابق ترتیب ذکر شده در اینجاست + . +
5. **Input not being mutated**. - In `fill!(x, v)`, `v` is *not* being mutated and it comes after `x`. +
+در تابع + `fill!(x, v)` + متغیر + `v` + تغییر نکرده و بعد از + `x` + می اید + . +
6. **Key**. - For associative collections, this is the key of the key-value pair(s). - For other indexed collections, this is the index. +
+برای مجموعه های انجمنی به اصطلاح + (associative) + این کلید زوج های کلید-مقدار + s + است و برای سایر مجموعه ها بیان کننده شماره + (index) + است. +
7. **Value**. - For associative collections, this is the value of the key-value pair(s). - In cases like [`fill!(x, v)`](@ref fill!), this is `v`. - +
+برای مجموعه های انجمنی به اصطلاح + (associative) + این مقدار زوج های کلید-مقدار + s + است و + در حالاتی مثل + `fill!(x, v)` + همان + 'v' + است + . +
+ 8. **Everything else**. - Any other arguments. +
+هر ارگومان دیگری +
9. **Varargs**. - This refers to arguments that can be listed indefinitely at the end of a function call. - For example, in `Matrix{T}(undef, dims)`, the dimensions can be given as a - [`Tuple`](@ref), e.g. `Matrix{T}(undef, (1,2))`, or as [`Vararg`](@ref)s, + +
+این اصطلاح به ارگومان هایی اشاره می کند که در انتهای فرایند صدا شدن + (call) + تابع + قابل لیست شدن باشند + . + به عنوان مثال در + `Matrix{T}(undef, dims)` + ابعاد ماتریس میتوانند به عنوان یک + `Tuple` + یعنی + `Matrix{T}(undef, (1,2)) + یا به عنوان + `Vararg`](@ref)s, e.g. `Matrix{T}(undef, 1, 2)`. +
10. **Keyword arguments**. - In Julia keyword arguments have to come last anyway in function definitions; they're - listed here for the sake of completeness. - -The vast majority of functions will not take every kind of argument listed above; the -numbers merely denote the precedence that should be used for any applicable arguments -to a function. - -There are of course a few exceptions. -For example, in [`convert`](@ref), the type should always come first. -In [`setindex!`](@ref), the value comes before the indices so that the indices can be -provided as varargs. - -When designing APIs, adhering to this general order as much as possible is likely to give -users of your functions a more consistent experience. - -## Don't overuse try-catch - -It is better to avoid errors than to rely on catching them. - -## Don't parenthesize conditions - -Julia doesn't require parens around conditions in `if` and `while`. Write: +
+ در جولیا ارگومان های کیبورد باید در هر صورت در اخر تعریف توابع بیایند + . + انها برای کامل شدن مطلب ابنجا ذکر شده اند + . +
+ اکثر قریب به اتفاق توابع از هر نوع ارگومان ذکر شده در بالا استفاده نمی کنند + . + اعداد صرفاً تقدم را نشان می دهند که باید برای هر ارگومان قابل استفاده یک تابع استفاده شود +
+ بدیهی است مقدار کمی استثنا وجود دارد. +
+ برای مثال در تابع + `convert` + تایپ (یا نوع )خروجی همیشه بایداول بیاید + . + در تابع + `setindex!` + مقدار قبل از اندیس ها می اید پس می توانند به عنوان + varargs + در نظر گرفته شوند + . +
+ درهنگام طراحی + API + ها + ، + پایبندی به این دستور کلی تا آنجا که ممکن است احتمالاً به کاربران شما تجربه سازگارتری میدهد + . +
+ +## Don't overuse try-catch(بیش از اندازه استفاده نکنید) +
+ بهتر است از گرفتن خطا اجتناب کنید تا اینکه انهارا + catch + کنید + . +
+ +## Don't parenthesize conditions(شرط ها را با پرانتز ننویسید) +
+ جولیا نیازی به پرانتز برای نوشتن شرط ها در + if + و + while + نیازی ندارد + . + بنویسید + : +
```julia if a == b ``` +
+ به جای + : +
-instead of: ```julia if (a == b) ``` -## Don't overuse `...` - -Splicing function arguments can be addictive. Instead of `[a..., b...]`, use simply `[a; b]`, -which already concatenates arrays. [`collect(a)`](@ref) is better than `[a...]`, but since `a` -is already iterable it is often even better to leave it alone, and not convert it to an array. - -## Don't use unnecessary static parameters - -A function signature: +## Don't overuse `...`(دوباره استفاده نکنید) +
+ اتصال + ارگومان توابع یا به اصطلاح + (splicing) + میتواند کاری خطرناک باشد + . + به جای + [a..., b...] + به سادگی از + [a; b] + استفاده کنید که خودش عمل + concatation + را برای ارایه انجام میدهد. + collect(a) + بهتر از + [a...] + است ولی زمانی که + a + خودش قابل تکرار است ،معمولا بهتر است که انها را خودش انجام دهیم و به ارایه تبدیل نکنیم + . + + + +
+ +## Don't use unnecessary static parameters(از پارامترهای غیر ضروری استاتیک استفاده نکنید) +
+ امضای تابع + : +
```julia foo(x::T) where {T<:Real} = ... ``` - -should be written as: +
+ بهتر است بدین صورت نوشته شود + : +
```julia foo(x::Real) = ... ``` - -instead, especially if `T` is not used in the function body. Even if `T` is used, it can be replaced -with [`typeof(x)`](@ref) if convenient. There is no performance difference. Note that this is -not a general caution against static parameters, just against uses where they are not needed. - -Note also that container types, specifically may need type parameters in function calls. See the -FAQ [Avoid fields with abstract containers](@ref) for more information. - -## Avoid confusion about whether something is an instance or a type - -Sets of definitions like the following are confusing: +
+ در مقابل ،مخصوصا اگر + T + در بدنه تابع استفاده نشده باشد، حتی اگر استفاده شدهباشد در صورت راحتی میتواند با + typeof(x) + جایگزین شود +و از لحاظ عملکردی فرقی ندارند. + توجه داشته باشید که این یک احتیاط کلی و عمومی در برابر پارامترهای استاتیک نیست بلکه فقط درمقابل مواقعی است که استفاده از انها لازم نباشد. +
+توجه داشته باشید که تایپ های دربرگیرنده + container types + به طور ویژهاحتیاج به تایپ پارامتر در صدا زدن تابع دارند . + برای اطلاعات بیشتر به + Avoid fields with abstract containers + مراجعه کنید. + +
+ +## Avoid confusion about whether something is an instance or a type(سردرگمی تایپ و نمونه ) +
+ مجموعه ای از تعاریف مانند تعاریف زیر گیج کننده هستند + : +
```julia foo(::Type{MyType}) = ... foo(::MyType) = foo(MyType) ``` - -Decide whether the concept in question will be written as `MyType` or `MyType()`, and stick to -it. - -The preferred style is to use instances by default, and only add methods involving `Type{MyType}` -later if they become necessary to solve some problems. - -If a type is effectively an enumeration, it should be defined as a single (ideally immutable struct or primitive) -type, with the enumeration values being instances of it. Constructors and conversions can check -whether values are valid. This design is preferred over making the enumeration an abstract type, -with the "values" as subtypes. - -## Don't overuse macros - -Be aware of when a macro could really be a function instead. - -Calling [`eval`](@ref) inside a macro is a particularly dangerous warning sign; it means the -macro will only work when called at the top level. If such a macro is written as a function instead, -it will naturally have access to the run-time values it needs. - -## Don't expose unsafe operations at the interface level - -If you have a type that uses a native pointer: +
+ تصمیم بگیرید که ایا مفهوم و موضوع مورد سوال به صورت + MyType + یا + MyType() + قابل نوشت است و از ان پیروی کنید. +
+ استایل و طراحی موردنظر ما استفاده پیش فرض از نمونه ها واگر واقعا اضافه کردن انها برای حل مسئله لازم بود ،بعدا فقط افزودن متد هایی که شامل + Type{MyType} + می شوند + . +
+ اگر تایپ به صورت موثر یک شکارشگر + enum + باشد بهتر است به صورت تایپ تکی + (single type ) + تعریف شود. + البته در حالت ایده ال) + بهتر است + immutable + (باشد +با مقدار شمارش شده + (enumration value) + یک نمونه یا شی از ان باشد کانستراکتور ها و کانورژن ها می توانند چک کنند که لیل مقادیر قابل اطمینان هستندد یا خیر . + این طراحی نسبت به حالتی که + enum + هارا یک تایپ ابسترکت تعریف کرده و "مقادیر" را به صورت زیر نوع تعریف کنیم ، بهتر است . + + + +
+ +## Don't overuse macros(زیاد از ماکرو استفاده نکنید) +
+ باید بدانیم که چه موقع یک ماکرو میتواند یک تابع به حساب اید . +
+ صدا کردن + eval + داخل یک ماکرو به طور خاص یک علامت خطرنام است . + به این معناست که ماکرو فقط در حالتی کار میکند که در بالاترین سطخ + (top level) + صدا شده باشد. + اگر این ماکرو به صورت تابع نوشته شده باشد،به طور طبیعی به مقادیر + run-time + ای که نیاز دارد دسترسی دارد + . +
+ + +## Don't expose unsafe operations at the interface level(در سطح رابط از عمل خطرناک استفاده نکنیذ) +
+ اگر شما یک تایپ دارید که از یک اشاره گر بومی استفاده می کند. + (native pointer): +
```julia mutable struct NativeType @@ -290,41 +640,64 @@ mutable struct NativeType ... end ``` - -don't write definitions like the following: +
+ تعاریف را مانند مثال زیر ننویسید + : +
```julia getindex(x::NativeType, i) = unsafe_load(x.p, i) ``` - -The problem is that users of this type can write `x[i]` without realizing that the operation is -unsafe, and then be susceptible to memory bugs. - -Such a function should either check the operation to ensure it is safe, or have `unsafe` somewhere -in its name to alert callers. +
+ مشکل اینجاست که کاربر این تایپ می تواند بنویسد + x[i] + بدون اینکه بفهمد این عملیات امن نیست. +و ممکن است دچار باگ های حافظه شود. +
+ چنین تابعی باید عملیات هایش چک شود تا تضمین شود که امن بوده است و یا یکجایی در اسم خود کلمه + unsafe + داشته باشد که صدازننده این تابع ،این موضوع را بداند. + +
## Don't overload methods of base container types - -It is possible to write definitions like the following: +
+ ممکن است تعاریفی مانند زیر بنویسیم + : +
```julia show(io::IO, v::Vector{MyType}) = ... ``` - -This would provide custom showing of vectors with a specific new element type. While tempting, -this should be avoided. The trouble is that users will expect a well-known type like `Vector()` -to behave in a certain way, and overly customizing its behavior can make it harder to work with. - -## Avoid type piracy - -"Type piracy" refers to the practice of extending or redefining methods in Base -or other packages on types that you have not defined. In some cases, you can get away with -type piracy with little ill effect. In extreme cases, however, you can even crash Julia -(e.g. if your method extension or redefinition causes invalid input to be passed to a -`ccall`). Type piracy can complicate reasoning about code, and may introduce -incompatibilities that are hard to predict and diagnose. - -As an example, suppose you wanted to define multiplication on symbols in a module: +
+ این ممکن است یک نمایشی از بردار ها بدهد که نوع اعضای ان یک نوع جدید باشد. + در حالیکه این کار وسوسه کننده است باید از ان خودداری شود. + مشکل این اسن که کاربر انتظار نوع مشهوری مثل + Vector() + را دارد پس به روش بالا عمل کردن و زیاد شخصی سازی توابع کار با ان ها را سخت تر می کند. +
+ + +## Avoid type piracy(از سطح امنیت دادن به تایپ ها بپرهیزید) +
+ کلمه + "Type piracy" + یا سطح امنیت تایپ + به عمل گسترش یا تعریف مجدد روش ها در + Base + اشاره دارد. + در بعضی از حالات ،با کمی تاثیر بد میتوانید با ان کنار بیایید ولی در حالات خیلی اکستریم، حتی میتواند منجر به خراب شدن جولیا شود +اگر تعریف مجدد یا اکستنشن تابع شما منجر به تولید ورودی غیر قابل قبولی که به تابع مثلا) + ccall + شود. + ( + Type piracy + میتواند منجر به پیچیده شدن کد و ایجاد مشکلاتی که به سختی قابل پیش بینی وتشخیص باشند ، شود. +
+ به عنوان مثال ،فرض کنید میخواهی د عمل ضرب را بر روی سمبل ها در یک ماژول تعریف کنید + : + +
```julia module A @@ -332,39 +705,92 @@ import Base.* *(x::Symbol, y::Symbol) = Symbol(x,y) end ``` - -The problem is that now any other module that uses `Base.*` will also see this definition. -Since `Symbol` is defined in Base and is used by other modules, this can change the -behavior of unrelated code unexpectedly. There are several alternatives here, including -using a different function name, or wrapping the `Symbol`s in another type that you define. - -Sometimes, coupled packages may engage in type piracy to separate features from definitions, -especially when the packages were designed by collaborating authors, and when the -definitions are reusable. For example, one package might provide some types useful for -working with colors; another package could define methods for those types that enable -conversions between color spaces. Another example might be a package that acts as a thin -wrapper for some C code, which another package might then pirate to implement a -higher-level, Julia-friendly API. - -## Be careful with type equality - -You generally want to use [`isa`](@ref) and [`<:`](@ref) for testing types, -not `==`. Checking types for exact equality typically only makes sense when comparing to a known -concrete type (e.g. `T == Float64`), or if you *really, really* know what you're doing. - -## Do not write `x->f(x)` - -Since higher-order functions are often called with anonymous functions, it is easy to conclude -that this is desirable or even necessary. But any function can be passed directly, without being -"wrapped" in an anonymous function. Instead of writing `map(x->f(x), a)`, write [`map(f, a)`](@ref). +
+ مشکل این است که الان هر ماژول دیگری که از + Base + استفاده میکند هم این تعریف یا تابع را میبیند و تا زمانی که + Symbol + در + Base + تعریف شده باشد،توسط دیگر ماژول ها استفاده میشود. + و این میتواند رفتار و عملکرد کد های در ضاهر بی ربط به ان را تغییر دهد و یا مختل کند . + یکسری راه های دیگر نیز برای این حالت وجود دارد، مانند در نظر گرفتن یک اسم دیگر برای تابع + و یا دسته بندی + (wrapping) + نماد + Symbol + در نوع دیگری که تعریف کردید. +
+ بعضی اوقات پکیج های + coupled + ممکن است به نوعی از + type piracy + برای جداکردن ویژگی هایی از تعاریف استفاده کرده باشند مخصوصا وقتی که ان بکیج ها توسط تعدادی برنامه نویس طراحی شده باشند. + که با هم همکاری داشتند وقتی که تعاریف و یا تابع ها قابل استفاده مجدد هستند . + برای مثال فرض کنید یک پکیج یکسری تایپ برای کار با رنگ ها فراهم میکند و پکیج دیگر میتواند یکسری تابع برای ان تایپ های که اجازه تبدیل بین فضا های رنگ را دارد ، تعریف کند + مثال دیگر ممکن است این باشد که یک پکیجیک + wrapper + برای کد ها به زبان + c + باشد درحالیکه دیگری باید یک + API + سطح بالا به زبان جولیا پیاده سازی مند. + +
+ +## Be careful with type equality(در برابر بودن تایپ دقت کنید) +
+ ما به صورت کلی دوست داریم که از + isa + و + <: + برای چک کردن نوع ارگومان استفاده کنیم . + و نه + == + چک کردن نوع به صورت تساوی دقیق با نماد قبل فقط موقعی خوب و منطقی به نظر میرسد که که با یک + concrete + تایپ داده شده مقایسه شود. + مثل + `T == Float64` + ویا حتما حتما حتما بدانید که چگونه از ان استفاده می کنید. + + +
+ + +## Do not write `x->f(x)`(این را ننویسید) + +
+ تا جایی که توابع با ترتیب بالاتر در اجرا معمولا به وسیله توابع ناشناس + anonymous + ساخته شده اند ،راحت است دریابیم که این خوب یا حتی لازم است . + ولی هر تابعی میتواند به صورت مستقیم پاس داده شود ،بدون اینکه در توابع ناشناس + (anonymous) + به اصطلاح + (wrapped) + شوند . +
+ به جای نوشتن + map(x->f(x), a) + بنویسید + map(f, a) + . + +
## Avoid using floats for numeric literals in generic code when possible - -If you write generic code which handles numbers, and which can be expected to run with many different -numeric type arguments, try using literals of a numeric type that will affect the arguments as -little as possible through promotion. - -For example, +
+ اگر شما یک کد عمومی یا + generic + بنویسید که روی اعداد کار میکند و انتظار دارید روی تمام ارگومان های تایپ عددی کار کند،سعی کنید از حرف های تایپ های عددی استفاده کنید که باعث میشود دامنه نوع ارگومان های قابل قبول مینیمال شود. + + +
+ +
+ به عنوان مثال + +
```jldoctest julia> f(x) = 2.0 * x @@ -379,8 +805,9 @@ julia> f(1/2) julia> f(1) 2.0 ``` - -while +
+ هنگامی که +
```jldoctest julia> g(x) = 2 * x @@ -395,11 +822,26 @@ julia> g(1/2) julia> g(1) 2 ``` - -As you can see, the second version, where we used an `Int` literal, preserved the type of the -input argument, while the first didn't. This is because e.g. `promote_type(Int, Float64) == Float64`, -and promotion happens with the multiplication. Similarly, [`Rational`](@ref) literals are less type disruptive -than [`Float64`](@ref) literals, but more disruptive than `Int`s: +
+ همان طور که می بینید ،ورژن دوم موقعی که ما از + Int + استفاده کردیم به عنوان نوع ارگومان ورودی در نظر گرفته شد ولی دفعه اول چنین اتفاقی نیافتاد . + زیرا +promote_type(Int, Float64) == Float64 + و ترفیع با ضرب اتفاق می افتد. + به طور مشابه حرف های + Rational + کمتر + مخل نوع هستند تا + حرف های + Float64 + ولی بیشتر از + Int + خراب کننده هستند + : + + +
```jldoctest julia> h(x) = 2//1 * x @@ -414,6 +856,12 @@ julia> h(1/2) julia> h(1) 2//1 ``` - -Thus, use `Int` literals when possible, with `Rational{Int}` for literal non-integer numbers, -in order to make it easier to use your code. +
+ پس به منظور سادگی استفاده از کد شما + در صورت امکان از کلمات + 'Int' + و برای اعداد غیر صحیح از + `Rational{Int}` + استفاده کنید + . +